Fix the instruction encoding for operands. Refactor mode to use explicit
instruction definitions per FIXME to be more consistent with loads/stores.
Fix disassembler accordingly. Add tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136509 91177308-0d34-0410-b5e6-96231b3b80d8
Fill in the missing fixed bits and the register operand bits of the instruction
encoding. Refactor the definition to make the mode explicit, which is
consistent with how loads and stores are normally represented and makes
parsing much easier. Add parsing aliases for pseudo-instruction variants.
Update the disassembler for the new representations. Add tests for parsing and
encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136479 91177308-0d34-0410-b5e6-96231b3b80d8
working on x86 (at least for trivial testcases); other architectures will
need more work so that they actually emit the appropriate instructions for
orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC,
Mips, and Alpha backends need such changes.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136457 91177308-0d34-0410-b5e6-96231b3b80d8
Also make PALIGNR masks to don't match 256-bits, which isn't supported
It's also a step to solve PR10489
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136448 91177308-0d34-0410-b5e6-96231b3b80d8
Later passes /are/ using this information when running the register
scavenger.
This fixes the second problem in PR10520.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136440 91177308-0d34-0410-b5e6-96231b3b80d8
This hidden llc option runs the machine code verifier after expanding
ARM pseudo-instructions, but before if-conversion.
The machine code verifier is much better at pointing out liveness errors
that can trip up the register scavenger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136439 91177308-0d34-0410-b5e6-96231b3b80d8
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
Add parsing support for BLX (immediate). Since the register operand version is
predicated and the label operand version is not, we have to use some special
handling to get the operand list right for matching.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136406 91177308-0d34-0410-b5e6-96231b3b80d8
Add parsing support that handles converting the lsb+width source into the
odd way we represent the instruction (an inverted bitfield mask).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136399 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM*AsmPrinter.
GenLibDeps.pl fails to detect vtable references. As this is the only
referenced symbol from LLVM*Desc to LLVM*AsmPrinter on optimized
builds, the algorithm that creates the list of libraries to be linked
into tools doesn't know about the dependency and sometimes places the
libraries on the wrong order, yielding error messages like this:
../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function
`llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)':
ARMMCTargetDesc.cpp:(.text._ZN4llvm14ARMInstPrinterC1ERKNS_9MCAsmInfoE
[llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo
const&)]+0x2a): undefined reference to `vtable for
llvm::ARMInstPrinter'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136328 91177308-0d34-0410-b5e6-96231b3b80d8
This can happen in cases where TableGen generated asm matcher cannot check
whether a register operand is in the right register class. e.g. mem operands.
rdar://8204588
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136292 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-mc gives an "invalid operand" error for instructions that take an unsigned
immediate which have the high bit set such as:
pblendw $0xc5, %xmm2, %xmm1
llvm-mc treats all x86 immediates as signed values and range checks them.
A small number of x86 instructions use the imm8 field as a set of bits.
This change only changes those instructions and where the high bit is not
ignored. The others remain unchanged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136287 91177308-0d34-0410-b5e6-96231b3b80d8
Encode the width operand as it encodes in the instruction, which simplifies
the disassembler and the encoder, by using the imm1_32 operand def. Add a
diagnostic for the context-sensitive constraint that the width must be in
the range [1,32-lsb].
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136264 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the rest of the extend instructions to not artificially distinguish
between a rotate of zero and a rotate of any other value. Replace the by-zero
versions with Pat<>'s for ISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136226 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the SXTB, SXTH, SXTB16, UXTB, UXTH, and UXTB16 instructions to not
have an 'r' and an 'r_rot' version, but just a single version with a rotate
that can be zero. Use plain Pat<>'s for the ISel of the non-rotated version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136225 91177308-0d34-0410-b5e6-96231b3b80d8
usage of the shuffle bitmask. Both work in 128-bit lanes without
crossing, but in the former the mask of the high part is the same
used by the low part while in the later both lanes have independent
masks. Handle this properly and and add support for vpermilpd.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136200 91177308-0d34-0410-b5e6-96231b3b80d8
On x86 we can't encode an immediate LHS of a sub directly. If the RHS comes from a XOR with a constant we can
fold the negation into the xor and add one to the immediate of the sub. Then we can turn the sub into an add,
which can be commuted and encoded efficiently.
This code is generated for __builtin_clz and friends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136167 91177308-0d34-0410-b5e6-96231b3b80d8
different from the previous 128-bit because they work in lanes.
Update a few comments and add testcases
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136157 91177308-0d34-0410-b5e6-96231b3b80d8
Allow the rot_imm operand to be optional. This sets the stage for refactoring
away the "rr" versions from the multiclasses and replacing them with Pat<>s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136154 91177308-0d34-0410-b5e6-96231b3b80d8
Start of cleaning this up a bit. First step is to remove the encoder hook by
storing the operand as the bits it'll actually encode to so it can just be
directly used. Map it to the assembly source values 8/16/24 when we print it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136152 91177308-0d34-0410-b5e6-96231b3b80d8
No intendeded functional change. Just cleaning up a bit to make things more
self-consistent in layout and style.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136095 91177308-0d34-0410-b5e6-96231b3b80d8
The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.
These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.
To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.
This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.
Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136023 91177308-0d34-0410-b5e6-96231b3b80d8
shuffle before inserting on a 256-bit vector.
- Add AVX versions of movd/movq instructions
- Introduce a few COPY patterns to match insert_subvector instructions.
This turns a trivial insert_subvector instruction into a register copy,
coalescing the xmm into a ymm and avoid emiting on more instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136002 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the Rn register encoding for both SSAT and USAT. Update the parsing of the
shift operand to correctly handle the allowed shift types and immediate ranges
and issue meaningful diagnostics when an illegal value or shift type is
specified. Add aliases to parse an ommitted shift operand (default value of
'lsl #0').
Add tests for diagnostics and proper encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135990 91177308-0d34-0410-b5e6-96231b3b80d8
Addresses PR10466, although the crash from that PR only triggers in cases where DAGCombine misses optimizing a shuffle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135980 91177308-0d34-0410-b5e6-96231b3b80d8
The shift immediate encoding, printing, etc. is handled directly by the
enclosing operand definition, so it should be a vanilla immediate, not a
nested complex operand (shift_imm).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135968 91177308-0d34-0410-b5e6-96231b3b80d8
Remove some inititalizers that are the same as the default, move defs next to
their (singular) uses and generally simplify some formatting of asm operand
definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135946 91177308-0d34-0410-b5e6-96231b3b80d8
unwind encoding for that function. This simply crawls through the prolog looking
for machine instrs marked as "frame setup". It can calculate from these what the
compact unwind should look like.
This is currently disabled because of needed linker support. But initial tests
look good.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135922 91177308-0d34-0410-b5e6-96231b3b80d8
The immediate is in the range 1-32, but is encoded as 0-31 in a 5-bit bitfield.
Update the representation such that we store the operand as 0-31, allowing us
to remove the encoder method and the special case handling in the disassembler.
Update the assembly parser and the instruction printer accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135823 91177308-0d34-0410-b5e6-96231b3b80d8
of doing the RAUW calls for the overflow value itself. This makes
it more consistent with how the rest of LegalizeDAG works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135788 91177308-0d34-0410-b5e6-96231b3b80d8
The header file was already properly located. The previous need for it
in Support had to do with the version string printing which was fixed in
r135757.
Also update build dependencies where libraries that needed the
functionality of the Target library (in the form of the TargetRegistry)
were picking it up via Support. This is pretty pervasive, essentially
every TargetInfo library (ARMInfo, etc) uses TargetRegistry, making it
depend on Target. All of these were previously just sneaking by.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135760 91177308-0d34-0410-b5e6-96231b3b80d8
the way to go. Doing this here will prevent several node matches later,
and would have to force looking all the way through several
VINSERTF128/VEXTRACTF128 chains to optimize simple things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135730 91177308-0d34-0410-b5e6-96231b3b80d8
and was actually very wrong, fix it and make it simpler. Also remove the
ConcatVectors function, which is unused now.
- Fix a introduction of useless nodes in r126664 and r126264. The
VUNPCKL* should never be introduced cause we don't want duplicate
nodes for 128 AVX and non-AVX modes, the actual instruction
difference only exists during isel, but not for target specific DAG
nodes. We only introduce V* target nodes when there is no 128-bit
version already there.
- Fix a fragile test and make it more useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135729 91177308-0d34-0410-b5e6-96231b3b80d8
Aliases for LDM/STM. The single-register versions should encode to LDR/STR
with writeback, but we don't (yet) get that correct. Neither does Darwin's
system assembler, though, so that's not a deal-breaker of a limitation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135702 91177308-0d34-0410-b5e6-96231b3b80d8
Stefanovic. I removed the part that actually emits the instructions cause
I want that to get in better shape first and in incremental steps. This
also makes it easier to review the upcoming parts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135678 91177308-0d34-0410-b5e6-96231b3b80d8
- Add more bitcasts for v16i16
- Since 135661 and 135662 already added the splat logic,
just add one more splat test for v16i16
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135663 91177308-0d34-0410-b5e6-96231b3b80d8
instruction introduced in AVX, which can operate on 128 and 256-bit vectors.
It considers a 256-bit vector as two independent 128-bit lanes. It can permute
any 32 or 64 elements inside a lane, and restricts the second lane to
have the same permutation of the first one. With the improved splat support
introduced early today, adding codegen for this instruction enable more
efficient 256-bit code:
Instead of:
vextractf128 $0, %ymm0, %xmm0
punpcklbw %xmm0, %xmm0
punpckhbw %xmm0, %xmm0
vinsertf128 $0, %xmm0, %ymm0, %ymm1
vinsertf128 $1, %xmm0, %ymm1, %ymm0
vextractf128 $1, %ymm0, %xmm1
shufps $1, %xmm1, %xmm1
movss %xmm1, 28(%rsp)
movss %xmm1, 24(%rsp)
movss %xmm1, 20(%rsp)
movss %xmm1, 16(%rsp)
vextractf128 $0, %ymm0, %xmm0
shufps $1, %xmm0, %xmm0
movss %xmm0, 12(%rsp)
movss %xmm0, 8(%rsp)
movss %xmm0, 4(%rsp)
movss %xmm0, (%rsp)
vmovaps (%rsp), %ymm0
We get:
vextractf128 $0, %ymm0, %xmm0
punpcklbw %xmm0, %xmm0
punpckhbw %xmm0, %xmm0
vinsertf128 $0, %xmm0, %ymm0, %ymm1
vinsertf128 $1, %xmm0, %ymm1, %ymm0
vpermilps $85, %ymm0, %ymm0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135662 91177308-0d34-0410-b5e6-96231b3b80d8
refactor the code and add a bunch of comments. The final shuffle
emitted by handling 256-bit types is suitable for the VPERM shuffle
instruction which is going to be introduced in a next commit (with
a testcase which cover this commit)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135661 91177308-0d34-0410-b5e6-96231b3b80d8
Move the shift operator and special value (32 encoded as 0 for PKHTB) handling
into the instruction printer. This cleans up a bit of the disassembler
special casing for these instructions, more easily handles not printing the
operand at all for "lsl #0" and prepares for correct asm parsing of these
operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135626 91177308-0d34-0410-b5e6-96231b3b80d8
Move common definitions for ARM and Thumb2 into ARMInstrFormats.td and rename
them to be a bit more descriptive that they're for the PKH instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135617 91177308-0d34-0410-b5e6-96231b3b80d8
The shift type is implied by the instruction (PKHBT vs. PKHTB) and so shouldn't
be also encoded as part of the shift value immediate. Otherwise we're able to
represent invalid instructions, plus it needlessly complicates the
representation. Preparatory work for asm parsing of these instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135616 91177308-0d34-0410-b5e6-96231b3b80d8
There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135611 91177308-0d34-0410-b5e6-96231b3b80d8
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135580 91177308-0d34-0410-b5e6-96231b3b80d8
TargetLoweringObjectFileImpl down to MCObjectFileInfo.
TargetAsmInfo is done to one last method. It's *almost* gone!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135569 91177308-0d34-0410-b5e6-96231b3b80d8
The system register spec should be case insensitive. The preferred form for
output with mask values of 4, 8, and 12 references APSR rather than CPSR.
Update and tidy up tests accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135532 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the parser to recognize the APSR and SPSR system register names. Add
and update tests accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135527 91177308-0d34-0410-b5e6-96231b3b80d8
Correct the handling of the 's' suffix when parsing ARM mode. It's only a
truly separate opcode in Thumb. Add test cases to make sure we handle
the s and condition suffices correctly, including diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135513 91177308-0d34-0410-b5e6-96231b3b80d8
Add range checking for the immediate operand and handle the "mov" mnemonic
choosing between encodings based on the value of the immediate. Add tests
for fixups, encoding choice and values, and diagnostic for out of range values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135500 91177308-0d34-0410-b5e6-96231b3b80d8
- In EmitAtomicBinaryPartword, mask incr in loopMBB only if atomic.swap is the
instruction being expanded, instead of masking it in thisMBB.
- Remove redundant Or in EmitAtomicCmpSwap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135495 91177308-0d34-0410-b5e6-96231b3b80d8
