Allow a target assembly parser to do context sensitive constraint checking
on a potential instruction match. This will be used, for example, to handle
Thumb2 IT block parsing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137675 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently we never added code to expand these pseudo instructions, and in
over a year, no one has noticed. Our register allocator must be awesome!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137551 91177308-0d34-0410-b5e6-96231b3b80d8
Tidy up the code a bit and push the definition of the value next to the uses
to try to minimize this sort of issue from arising again while I'm at it.
rdar://9945172
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137525 91177308-0d34-0410-b5e6-96231b3b80d8
vectors. It operates on 128-bit elements instead of regular scalar
types. Recognize shuffles that are suitable for VPERM2F128 and teach
the x86 legalizer how to handle them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137519 91177308-0d34-0410-b5e6-96231b3b80d8
integer register to a floating point register. It is not valid to interpret
the value of a floating pointer register as part of a double precision
floating point value after a single precision floating point computational
or move instruction stores its result to the register.
- In the test case, the following code is generated before this patch is
applied:
mtc1 $zero, $f2 ; unformatted copy to $f2
mov.s $f0, $f2 ; $f0 is in single format
sdc1 $f12, 0($sp)
mov.s $f1, $f2 ; $f1 is in single format
c.eq.d $f12, $f0 ; $f0 cannot be interpreted as double
- The following code is generated after this patch is applied:
mtc1 $zero, $f0 ; unformatted copy to $f0
mtc1 $zero, $f1 ; unformatted copy to $f1
c.eq.d $f12, $f0 ; $f0 can be interpreted as double
Bhanu Chetlapalli and Chris Dearman at MIPS technologies reported this bug and
provided the test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137484 91177308-0d34-0410-b5e6-96231b3b80d8
inserts and extracts. This simple combine makes us generate only 1
instruction instead of 11 in the v8 case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137362 91177308-0d34-0410-b5e6-96231b3b80d8
(for example, after integer operation), do not pack the registers into a YMM
before saving. Its better to save as two XMM registers.
Before:
vinsertf128 $1, %xmm3, %ymm0, %ymm3
vinsertf128 $0, %xmm1, %ymm3, %ymm1
vmovaps %ymm1, 416(%rsp)
After:
vmovaps %xmm3, 416+16(%rsp)
vmovaps %xmm1, 416(%rsp)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137308 91177308-0d34-0410-b5e6-96231b3b80d8
data in-register prior to saving to memory. When we reorder the data in memory
we prevent the need to save multiple scalars to memory, making a single regular
store.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137238 91177308-0d34-0410-b5e6-96231b3b80d8
def : Pat<(X86Movss VR128:$src1,
(bc_v4i32 (v2i64 (load addr:$src2)))),
(MOVLPSrm VR128:$src1, addr:$src2)>;
This matches a MOVSS dag with a MOVLPS instruction. However, MOVSS will replace only the low 32 bits of the register, while the MOVLPS instruction will replace the low 64 bits. A testcase is added and illustrates the bug and also modified the one that was already present. Patch by Tanya Lattner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137227 91177308-0d34-0410-b5e6-96231b3b80d8
On Cortex-A8, we use the NEON v2f32 instructions for f32 arithmetic. For
better latency, we also send D-register copies down the NEON pipeline by
translating them to vorr instructions.
This patch promotes even S-register copies to D-register copies when
possible so they can also go down the NEON pipeline. Example:
vldr.32 s0, LCPI0_0
loop:
vorr d1, d0, d0
loop2:
...
vadd.f32 d1, d1, d16
The vorr instruction looked like this after regalloc:
%S2<def> = COPY %S0, %D1<imp-def>
Copies involving odd S-registers, and copies that don't define the full
D-register are left alone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137182 91177308-0d34-0410-b5e6-96231b3b80d8
This new disassembler can correctly decode all the testcases that the old one did, though
some "expected failure" testcases are XFAIL'd for now because it is not (yet) as strict in
operand checking as the old one was.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137144 91177308-0d34-0410-b5e6-96231b3b80d8
Allow labels for load/store instructions when parsing. There's encoding
issues, still, so this doesn't work all the way through, yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137064 91177308-0d34-0410-b5e6-96231b3b80d8
These the methods are target-independent since they simply scan the
memory operands. They can live in TargetInstrInfoImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137063 91177308-0d34-0410-b5e6-96231b3b80d8
X86FloatingPoint keeps track of pending ST registers for an upcoming
inline asm instruction with fixed stack register constraints. It does
this by remembering which FP register holds the value that should appear
at a fixed stack position for the inline asm.
When that FP register is killed before the inline asm, make sure to
duplicate it to a scratch register, so the ST register still has a live
FP reference.
This could happen when the same FP register was copied to two ST
registers, or when a spill instruction is inserted between the ST copy
and the inline asm.
This fixes PR10602.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137050 91177308-0d34-0410-b5e6-96231b3b80d8
More parsing support for indexed loads. Fix pre-indexed with writeback
parsing for register offsets and handle basic post-indexed offsets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136982 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor STR[B] pre and post indexed instructions to use addressing modes for
memory operands, which is necessary for assembly parsing and is more consistent
with the rest of the memory instruction definitions. Make some incremental
progress on refactoring away the mega-operand addrmode2 along the way, which
is nice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136978 91177308-0d34-0410-b5e6-96231b3b80d8
The immediate portion of the operand is just a boolean (the 'U' bit indicating
add vs. subtract). Treat it as such.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136969 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance support for LDR instruction assembly parsing for post-indexed
addressing with immediate values. Add tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136940 91177308-0d34-0410-b5e6-96231b3b80d8
Memory operand parsing is a bit haphazzard at the moment, in no small part
due to the even more haphazzard representations of memory operands in the .td
files. Start cleaning that all up, at least a bit.
The addressing modes in the .td files will be being simplified to not be
so monolithic, especially with regards to immediate vs. register offsets
and post-indexed addressing. addrmode3 is on its way with this patch, for
example.
This patch is foundational to enable going back to smaller incremental patches
for the individual memory referencing instructions themselves. It does just
enough to get the basics in place and handle the "make check" regression tests
we already have.
Follow-up work will be fleshing out the details and adding more robust test
cases for the individual instructions, starting with ARM mode and moving from
there into Thumb and Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136845 91177308-0d34-0410-b5e6-96231b3b80d8
The testcase looks extremely fragile, so I'm adding an assertion which should catch any cases like this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136711 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen deps introduced in r136023. This completes the fixing that
dgregor started in r136621. Sorry for missing these the first time
around.
This should fix some of the random race-condition failures people are
still seeing with CMake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136643 91177308-0d34-0410-b5e6-96231b3b80d8
avoid returning early for v8i32 types, which would only be valid for
vector with all zeros. Also split the handling of zeros and ones into separate
checking logic since they are handled differently. This fixes PR10547
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136642 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the 'resume' instruction class, IR parsing, and bitcode reading and
writing. The 'resume' instruction resumes propagation of an existing (in-flight)
exception whose unwinding was interrupted with a 'landingpad' instruction (to be
added later).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136589 91177308-0d34-0410-b5e6-96231b3b80d8
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
