I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.
rdar://problem/14817358
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189096 91177308-0d34-0410-b5e6-96231b3b80d8
This uses the ARMcmov pattern that Tim cleaned up in r188995.
Thanks to Simon Tatham for his floating point help!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189024 91177308-0d34-0410-b5e6-96231b3b80d8
The instruction to convert between floating point and fixed point representations
takes an immediate operand for the number of fractional bits of the fixed point
value. ARMARM specifies that when that number of bits is zero, the assembler
should encode floating point/integer conversion instructions.
This patch adds the necessary instruction aliases to achieve this behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189009 91177308-0d34-0410-b5e6-96231b3b80d8
The function call to external function should come with PLT relocation
type if the PIC relocation model is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189002 91177308-0d34-0410-b5e6-96231b3b80d8
Back in the mists of time (2008), it seems TableGen couldn't handle the
patterns necessary to match ARM's CMOV node that we convert select operations
to, so we wrote a lot of fairly hairy C++ to do it for us.
TableGen can deal with it now: there were a few minor differences to CodeGen
(see tests), but nothing obviously worse that I could see, so we should
probably address anything that *does* come up in a localised manner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188995 91177308-0d34-0410-b5e6-96231b3b80d8
The code for 'Q' and 'R' operand modifiers needs to look through tied
operands to discover the register class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188990 91177308-0d34-0410-b5e6-96231b3b80d8
Indirect tail-calls shouldn't use R9 for the branch destination, as
it's not reliably a call-clobbered register.
rdar://14793425
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188967 91177308-0d34-0410-b5e6-96231b3b80d8
According to the ARM specification, "mov" is a valid mnemonic for all Thumb2 MOV encodings.
To achieve this, the patch adds one instruction alias with a special range condition to avoid collision with the Thumb1 MOV.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188901 91177308-0d34-0410-b5e6-96231b3b80d8
Update testcase to be more careful about checking register
values. While regexes are general goodness for these sorts of
testcases, in this example, the registers are constrained by
the calling convention, so we can and should check their
explicit values.
rdar://14779513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188819 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we used a const-pool load for virtually all 64-bit floating values.
Actually, we can get quite a few common values (including 0.0, 1.0) via "vmov"
instructions of one stripe or another.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188773 91177308-0d34-0410-b5e6-96231b3b80d8
The Thumb2 add immediate is in fact defined for SP. The manual is misleading as it points to a different section for add immediate with SP, however the encoding is the same as for add immediate with register only with the SP operand hard coded. As such add immediate with SP and add immediate with register can safely be treated as the same instruction.
All the patch does is adjust a register constraint on an instruction alias.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188676 91177308-0d34-0410-b5e6-96231b3b80d8
When patching inlineasm nodes to use GPRPair for 64-bit values, we
were dropping the information that two operands were tied, which
effectively broke the live-interval of vregs affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188643 91177308-0d34-0410-b5e6-96231b3b80d8
Properly constrain the operand register class for instructions used
in [sz]ext expansion. Update more tests to use the verifier now that
we're getting the register classes correct.
rdar://12594152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188594 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the generic instruction selection helper functions to constrain
the register classes of their input operands. For non-physical register
references, the generic code needs to be careful not to mess that up
when replacing references to result registers. As the comment indicates
for MachineRegisterInfo::replaceRegWith(), it's important to call
constrainRegClass() first.
rdar://12594152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188593 91177308-0d34-0410-b5e6-96231b3b80d8
Lots of machine verifier errors result from using a plain GPR regclass
for incoming argument copies. A more restrictive rGPR class is more
appropriate since it more accurately represents what's happening, plus
it lines up better with isel later on so the verifier is happier.
Reduces the number of ARM fast-isel tests not running with the verifier
enabled by over half.
rdar://12594152
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188592 91177308-0d34-0410-b5e6-96231b3b80d8
This unbreaks PIC with fast isel on ELF targets (PR16717). The output matches
what GCC and SDag do for PIC but may not cover all of the many flavors of PIC
that exist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188551 91177308-0d34-0410-b5e6-96231b3b80d8
Thumb2 literal loads use an offset encoding which allows for
negative zero. This fixes parsing and encoding so that #-0
is correctly processed. The parser represents #-0 as INT32_MIN.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188549 91177308-0d34-0410-b5e6-96231b3b80d8
There are many Thumb instructions which take 12-bit immediates encoded in a special
8-byte value + 4-byte rotator form. Not all numbers are represented, and it's legal
to transform an assembly instruction to be able to encode the immediate.
For example: AND and BIC are complementary instructions; one can switch the AND
to a BIC as long as the immediate is complemented.
The intent is to switch one instruction into its complementary one when the immediate
cannot be encoded in the form requested in the original assembly and when the
complementary immediate is encodable.
The patch addresses two issues:
1. definition of t2SOImmNot immediate - it has to check that the orignal value is
not encoded naturally
2. t2AND and t2BIC instruction aliases which should use the Thumb2 SOImm operand
rather than the ARM one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188548 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch this flag is IOS specific, but is also
useful for bare project like bootloaders / kernels etc,
since movw / movt prevents simple relocation. Therefore
make this flag more commonly available.
note: this patch depends on a similiar rename in clang
Patch by Jeroen Hofstee.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188487 91177308-0d34-0410-b5e6-96231b3b80d8
r9 is defined as a platform-specific register in the ARM EABI.
It can be reserved for a special purpose or be used as a general
purpose register. Add support for reserving r9 for all ARM, while
leaving the IOS usage unchanged.
Patch by Jeroen Hofstee.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188485 91177308-0d34-0410-b5e6-96231b3b80d8
1. The offset range for Thumb1 PC relative loads is [0..1020] and not [-1024..1020]
2. Thumb2 PC relative loads may define the PC, so the restriction placed on target register is removed
3. Removes unneeded alias between "ldr.n" and t1LDRpci. ".n" is actually stripped by both tablegen
and the ASM parser, so this alias rule really does nothing
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188466 91177308-0d34-0410-b5e6-96231b3b80d8
When determining if two different loads are from the same base address,
this patch allows one load to use a t2LDRi8 address mode and another to
use a t2LDRi12 address mode. The current implementation is very
conservative and this allows the case of differing Thumb2 byte loads to
be considered. Allowing these differing modes instead of forcing the exact
same opcode is useful for situations where one opcodes loads from a base
address+1 and a second opcode loads for a base address-1.
Patch by Daniel Stewart.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188385 91177308-0d34-0410-b5e6-96231b3b80d8
Use it to avoid repeating ourselves too often. Also store MVT::SimpleValueType
in the TTI tables so they can be statically initialized, MVT's constructors
create bloated initialization code otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188095 91177308-0d34-0410-b5e6-96231b3b80d8
In Thumb1, only one variant is supported: CPS{effect} {flags}
Thumb2 supports three:
CPS{effect}.W {flags}
CPS{effect} {flags} {mode}
CPS {mode}
Canonically, .W should be used only when ambiguity is present between encodings of different width.
The wide suffix is still accepted for the latter two forms via aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188071 91177308-0d34-0410-b5e6-96231b3b80d8
The long encoding for Thumb2 unconditional branches is broken.
Additionally, there is no range checking for target operands; as such
for instructions originating in assembly code, only short Thumb encodings
are generated, regardless of the bitsize needed for the offset.
Adding range checking is non trivial due to the representation of Thumb
branch instructions. There is no true difference between conditional and
unconditional branches in terms of operands and syntax - even unconditional
branches have a predicate which is expected to match that of the IT block
they are in. Yet, the encodings and the permitted size of the offset differ.
Due to this, for any mnemonic there are really 4 encodings to choose for.
The problem cannot be handled in the parser alone or by manipulating td files.
Because the parser builds first a set of match candidates and then checks them
one by one, whatever tablegen-only solution might be found will ultimately be
dependent of the parser's evaluation order. What's worse is that due to the fact
that all branches have the same syntax and the same kinds of operands, that
order is governed by the lexicographical ordering of the names of operand
classes...
To circumvent all this, any necessary disambiguation is added to the instruction
validation pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188067 91177308-0d34-0410-b5e6-96231b3b80d8
This is the only Thumb2 instruction defined with "t" prefix; all other Thumb2 instructions have "t2" prefix (e.g. "t2CDP2" which is defined immediately afterwards).
Patch by Artyom Skrobov.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187973 91177308-0d34-0410-b5e6-96231b3b80d8
Without explicit dependencies, both per-file action and in-CommonTableGen action could run in parallel.
It races to emit *.inc files simultaneously.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187780 91177308-0d34-0410-b5e6-96231b3b80d8
Using an object to do the cleanup may look like overkill, but it's safer and nicer than putting deletes everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187696 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the multiple breakages on ARM test-suite after the SLP
vectorizer was introduced by default on O3. The problem was an illegal
vector type on ARMTTI::getCmpSelInstrCost() <3 x i1> which is not simple.
The guard protects this code from breaking (cause of the problems) but
doesn't fix the issue that is generating the odd vector in the first
place, which also needs to be investigated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187658 91177308-0d34-0410-b5e6-96231b3b80d8
Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187618 91177308-0d34-0410-b5e6-96231b3b80d8
While the .td entry is nice and all, it takes a pretty gross hack in
ARMAsmParser::ParseInstruction() because of handling of other "subs"
instructions to get it to match. Ran it by Jim Grosbach and he said it was
about what he expected to make this work given the existing code.
rdar://14214063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187530 91177308-0d34-0410-b5e6-96231b3b80d8
When simplifying a (or (and B A) (and C ~A)) to a (VBSL A B C) ensure that the
bitwidth of the second operands to both ands match before comparing the negation
of the values.
Split the check of the value of the second operands to the ands. Move the cast
and variable declaration slightly higher to make it slightly easier to follow.
Bug-Id: 16700
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187404 91177308-0d34-0410-b5e6-96231b3b80d8
do in the SDag when lowering references to the GOT: use
ARMConstantPoolSymbol rather than creating a dummy global variable. The
computation of the alignment still feels weird (it uses IR types and
datalayout) but it preserves the exact previous behavior. This change
fixes the memory leak of the global variable detected on the valgrind
leak checking bot.
Thanks to Benjamin Kramer for pointing me at ARMConstantPoolSymbol to
handle this use case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187303 91177308-0d34-0410-b5e6-96231b3b80d8
me) should start watching this bot more as its catching lots of bugs.
The fix here is to not construct the global if we aren't going to need
it. That's cheaper anyways, and globals have highly predictable types in
practice. I've added an assert to catch skew between our manual testing
of the type and the actual type just for paranoia's sake.
Note that this pattern is actually fine in most globals because when you
build a global with a module it automatically is moved to be owned by
that module. But here, we're in isel and don't really want to do that.
The solution of not creating a global is simpler anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187302 91177308-0d34-0410-b5e6-96231b3b80d8
When vectors are built from a single value, the ARM lowering issues a
scalar_to_vector node.
This node is then always morphed into a move from the general purpose unit to
the vector unit.
When the value comes from a load, this can be simplified into a vector load to
the right lane.
This patch changes the lowering of insert_vector_elt to expose a vector
friendly pattern in this situation.
This is a step toward fixing <rdar://problem/14170854>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186999 91177308-0d34-0410-b5e6-96231b3b80d8
instructions. With this patch:
1. ldr.n is recognized as mnemonic for the short encoding
2. ldr.w is recognized as menmonic for the long encoding
3. ldr will map to either short or long encodings depending on the size of the offset
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186831 91177308-0d34-0410-b5e6-96231b3b80d8
