Summary:
I believe legalization is really expecting that ReplaceNodeResults will return something with the same type as the thing that's being legalized. Ultimately, it uses the output to replace the uses in the DAG so the type should match to make that work.
There are two relevant cases here. When crbits are enabled, then i1 is a legal type and getSetCCResultType should return i1. In this case, the truncate will be between i1 and i1 and should be removed (SelectionDAG::getNode does this). Otherwise, getSetCCResultType will be i32 and the legalizer will promote the truncate to be i32 -> i32 which will be similarly removed.
With this fixed we can remove some code from PromoteIntRes_SETCC that seemed to only exist to deal with the intrinsic being replaced with a larger type without changing the other operand. With the truncate being used for connectivity this doesn't happen anymore.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: nemanjai, llvm-commits, kbarton
Differential Revision: https://reviews.llvm.org/D41654
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321959 91177308-0d34-0410-b5e6-96231b3b80d8
The instructions that load 64-bits or an xmm register should be TB_NO_REVERSE to avoid the load being widened during unfold. The instructions that load 128-bits need to ensure 128-bit alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321956 91177308-0d34-0410-b5e6-96231b3b80d8
EVEX_B means different things for memory and register forms. The instructions should not be considered equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321954 91177308-0d34-0410-b5e6-96231b3b80d8
The memory form of the xmm->xmm version only writes 64-bits. If we use it in the folding tables and its get used for a stack spill, only half the slot will be written. Then a reload may read all 128-bits which will pull in garbage. But without the spill the upper bits of the register would have been zero. By not folding we would preserve the zeros.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321950 91177308-0d34-0410-b5e6-96231b3b80d8
We don't do fine grained feature control like this on features prior to AVX512.
We do still have checks in place in the assembly parser itself that prevents %zmm references or %xmm16-31 from being parsed without at least -mattr=avx512f. Same for rounding control and mask operands. That will prevent the table matcher from matching for any instructions that need those features and that's probably good enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321947 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency use the _Int version of VCVTTSD2SIrr_Int and VCVTTSD2SIrm_Int for the assembler as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321944 91177308-0d34-0410-b5e6-96231b3b80d8
We should always prefer the VEX encoded version of these instructions. There is no advantage to the EVEX version.
Fixes PR35837.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321939 91177308-0d34-0410-b5e6-96231b3b80d8
This is the last step needed to fix PR33325:
https://bugs.llvm.org/show_bug.cgi?id=33325
We're trading branch and compares for loads and logic ops.
This makes the code smaller and hopefully faster in most cases.
The 24-byte test shows an interesting construct: we load the trailing scalar
elements into vector registers and generate the same pcmpeq+movmsk code that
we expected for a pair of full vector elements (see the 32- and 64-byte tests).
Differential Revision: https://reviews.llvm.org/D41714
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321934 91177308-0d34-0410-b5e6-96231b3b80d8
Without this we allow "vmovd %rax, %xmm0", but not "vmovd %rax, %xmm16"
This exists due to continue a silly bug where really old versions of the GNU assembler required movd instead of movq on these instructions. This compatibility hack then crept forward to avx version too, but we didn't propagate it to avx512.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321903 91177308-0d34-0410-b5e6-96231b3b80d8
This behavior existed to work with an old version of the gnu assembler on MacOS that only accepted this form. Newer versions of GNU assembler and the current LLVM derived version of the assembler on MacOS support movq as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321898 91177308-0d34-0410-b5e6-96231b3b80d8
Currently the assembler would accept, e.g. `ldr r0, [s0, #12]` and similar.
This patch add checks that only general-purpose registers are used in address
operands, shifted registers, and shift amounts.
Differential revision: https://reviews.llvm.org/D39910
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321866 91177308-0d34-0410-b5e6-96231b3b80d8
Select G_PHI to PHI and manually constrain the result register. This is
very similar to how COPY is handled, so extract and reuse some of that
code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321797 91177308-0d34-0410-b5e6-96231b3b80d8
We used to handle G_CONSTANT with pointer type by forcing the type of
the result register to s32 and then letting TableGen handle it.
Unfortunately, setting the type only works for generic virtual
registers, that haven't yet been constrained to a register class (e.g.
those used only by a COPY later on). If the result register has already
been constrained as a use of a previously selected instruction, then
setting the type will assert.
It would be nice to be able to teach TableGen to select pointer
constants the same as integer constants, but since it's such an edge
case (at the moment the only pointer constant that we're generally
interested in is 0, and that is mostly used for comparisons and selects,
which are also not supported by TableGen) it's probably not worth the
effort right now. Instead, handle pointer constants with some trivial
handwritten code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321793 91177308-0d34-0410-b5e6-96231b3b80d8
This custom inserter was added in r124272 at which time it added about bunch of Defs for Win64. In r150708, those defs were removed leaving only the "return BB". So I think this means the custom inserter is a NOP these days.
This patch removes the remaining code and stops tagging the instructions for custom insertion
Differential Revision: https://reviews.llvm.org/D41671
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321747 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we use SIGN_EXTEND in lowerMasksToReg as part of calling convention setup, but we don't require a specific value for the upper bits.
This patch changes it to ANY_EXTEND which will be lowered as SIGN_EXTEND if it ends up sticking around.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321746 91177308-0d34-0410-b5e6-96231b3b80d8
After D41349, we can now directly access MCSubtargetInfo from
createARM*AsmBackend. This patch makes use of this, avoiding the need to
create a fresh MCSubtargetInfo (which was previously always done with a blank
CPU and feature string). Given the total size of the change remains pretty
tiny and we're removing the old explicit destructor, I changed the STI field
to a reference rather than a pointer.
Differential Revision: https://reviews.llvm.org/D41693
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321707 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a register class for SVE predicate operands that can only be p0-p7 (as opposed to p0-p15)
Patch [1/3] in a series to add predicated ADD/SUB instructions for SVE.
Reviewers: rengolin, mcrosier, evandro, fhahn, echristo, olista01, SjoerdMeijer, javed.absar
Reviewed By: fhahn
Subscribers: aemerson, javed.absar, tschuett, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D41441
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321699 91177308-0d34-0410-b5e6-96231b3b80d8
Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend.
D20830 threaded an MCSubtargetInfo reference through
MCAsmBackend::relaxInstruction, but this isn't the only function that would
benefit from access. This patch removes the Triple and CPUString arguments
from createMCAsmBackend and replaces them with MCSubtargetInfo.
This patch just changes the interface without making any intentional
functional changes. Once in, several cleanups are possible:
* Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend
* Support 16-bit instructions when valid in MipsAsmBackend::writeNopData
* Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl
* Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221)
This change initially exposed PR35686, which has since been resolved in r321026.
Differential Revision: https://reviews.llvm.org/D41349
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321692 91177308-0d34-0410-b5e6-96231b3b80d8
Craig Topper