Split am6offset into fixed and register offset variants so the instruction
encodings are explicit rather than relying an a magic reg0 marker.
Needed to being able to parse these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142853 91177308-0d34-0410-b5e6-96231b3b80d8
that the set of callee-saved registers is correct for the specific platform.
<rdar://problem/10313708> & ctor_dtor_count & ctor_dtor_count-2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142706 91177308-0d34-0410-b5e6-96231b3b80d8
Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.
Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142670 91177308-0d34-0410-b5e6-96231b3b80d8
On spec/gcc, this caused a codesize improvement of ~1.9% for ARM mode and ~4.9% for Thumb(2) mode. This is
codesize including literal pools.
The pools themselves doubled in size for ARM mode and quintupled for Thumb mode, leaving suggestion that there
is still perhaps redundancy in LLVM's use of constant pools that could be decreased by sharing entries.
Fixes PR11087.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142530 91177308-0d34-0410-b5e6-96231b3b80d8
register and then compare against that" method when it's too large. We have to
move the value into the register in the "movw, movt" pair of instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142440 91177308-0d34-0410-b5e6-96231b3b80d8
register and then compare against that" method when it's too large. We have to
move the value into the register in the "movw, movt" pair of instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142437 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up the patterns, fix comments, and avoid confusing both tools
and coders. Note that the special adds/subs SelectionDAG nodes no
longer have the dummy cc_out operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142397 91177308-0d34-0410-b5e6-96231b3b80d8
predecessor to remove the jump to it as well. Delay clearing the 'landing pad'
flag until after the jumps have been removed. (There is an implicit assumption
in several modules that an MBB which jumps to a landing pad has only two
successors.)
<rdar://problem/10304224>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142390 91177308-0d34-0410-b5e6-96231b3b80d8
Use the custom inserter for the ARM setjmp intrinsics. Instead of creating the
SjLj dispatch table in IR, where it frequently violates serveral assumptions --
in particular assumptions made by the landingpad instruction about what can
branch to a landing pad and what cannot. Performing this in the back-end allows
us to violate these assumptions without the IR getting angry at us.
It also allows us to perform a small optimization. We can shove the address of
the dispatch's basic block into the function context and not have to add code
around the setjmp to check for the return value and jump to the dispatch.
Neat, huh?
<rdar://problem/10116753>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142294 91177308-0d34-0410-b5e6-96231b3b80d8
NEON immediates are "interesting". Start of the work to handle parsing them
in an 'as' compatible manner. Getting the matcher to play nicely with
these and the floating point immediates from VFP is an extra fun wrinkle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142293 91177308-0d34-0410-b5e6-96231b3b80d8
Once the intrinsics are marked as having a custom inserter, it will call this
method to emit the dispatch table into the machine function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142245 91177308-0d34-0410-b5e6-96231b3b80d8
It really doesn't, but when r141929 removed the hasSideEffects flag from
this instruction, it caused miscompilations. I am guessing that it got
moved across a stack pointer update.
Also clear isRematerializable after checking that this instruction is
in fact never rematerialized in the nightly test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142030 91177308-0d34-0410-b5e6-96231b3b80d8
rdar://10288916 is tracking this fix.
In the past, instcombine and other passes were promoting alloca alignment past
the natural alignment, resulting in dynamic stack realignment. Lang's work now
prevents this from happening (LLVM commit r141599). Now that this really
shouldn't happen report a fatal error rather than silently generate bad code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142028 91177308-0d34-0410-b5e6-96231b3b80d8
The callee-saved registers cannot be live across an invoke call because the
control flow may continue along the exceptional edge. When this happens, all of
the callee-saved registers are no longer valid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142018 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen infers unmodeled side effects on instructions without a
pattern. Fix some instruction definitions where that was overlooked.
Also raise an error if a rematerializable instruction has unmodeled side
effects. That doen't make any sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141929 91177308-0d34-0410-b5e6-96231b3b80d8
The disassembler needs to use the AM5 factory methods instead of just
building up the immediate directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141819 91177308-0d34-0410-b5e6-96231b3b80d8
When widening a copy, we are reading a larger register that may not be
live. Use an <undef> flag to tell the register scavenger and machine
code verifier that we know the value isn't defined.
We now widen:
%S6<def> = COPY %S4<kill>, %D3<imp-def>
into:
%D3<def> = VMOVD %D2<undef>, pred:14, pred:%noreg, %S4<imp-use,kill>
This also keeps the <kill> flag on %S4 so we don't inadvertently kill a
live value in %S5.
Finally, ensure that ARMBaseInstrInfo::setExecutionDomain() preserves
the <undef> flag when converting VMOVD to VORR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141746 91177308-0d34-0410-b5e6-96231b3b80d8
Fill out the rest of the encoding information, update to properly mark
the LDC/STC instructions as predicable while the LDC2/STC2 instructions are
not, and adjust the parser accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141721 91177308-0d34-0410-b5e6-96231b3b80d8
The VMOVS widening needs to look at the implicit COPY operands. Trying
to dig out the COPY instruction from an iterator in copyPhysReg() is the
wrong approach.
The expandPostRAPseudo() hook gets to look at COPY instructions before
they are converted to copyPhysReg() calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141619 91177308-0d34-0410-b5e6-96231b3b80d8
promoting allocas to preferred alignments that exceed the natural
alignment. This avoids some potentially expensive dynamic stack realignments.
The natural stack alignment is set in target data strings via the "S<size>"
option. Size is in bits and must be a multiple of 8. The natural stack alignment
defaults to "unspecified" (represented by a zero value), and the "unspecified"
value does not prevent any alignment promotions. Target maintainers that care
about avoiding promotions should explicitly add the "S<size>" option to their
target data strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141599 91177308-0d34-0410-b5e6-96231b3b80d8
block. E.g., if we have:
movs r1, r1
rsb r1, 0
movs r2, r2
rsb r2, 0
we don't want this to be converted to:
movs r1, r1
movs r2, r2
itt mi
rsb r1, 0
rsb r2, 0
PR11107 & <rdar://problem/10259534>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141589 91177308-0d34-0410-b5e6-96231b3b80d8
ARMII::AddrModeT1_s, we need to take into account that if the frame register is
ARM::SP, then the number of bits is 8. If it's not ARM::SP, then the number of
bits is 5.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141529 91177308-0d34-0410-b5e6-96231b3b80d8
the tADDrSPi instruction can't be used. Make sure we're updating the opcode
to tADDi3 in all cases.
rdar://10254707
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141523 91177308-0d34-0410-b5e6-96231b3b80d8
successor. Remove the old landing pad from their successor list, because it's
now the successor of the dispatch block. Now that the landing pad blocks are no
longer the destination of invokes, we can mark them as normal basic blocks
instead of landing pads.
This more closely resembles what the CFG is actually doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141436 91177308-0d34-0410-b5e6-96231b3b80d8
Consider:
mov r8, r11 fred
Previously, we issued the not very informative:
x.s:6:1: error: unexpected token in argument list
^
Now we generate:
x.s:5:14: error: unexpected token in argument list
mov r8, r11 fred
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141380 91177308-0d34-0410-b5e6-96231b3b80d8
others. They take the call site value. Determine if it's a proper value. And
then jumps to the correct call site via a jump table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141341 91177308-0d34-0410-b5e6-96231b3b80d8
to an infinite loop because of the def-use chains.
Also use a frame load instead of store for the LD instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141263 91177308-0d34-0410-b5e6-96231b3b80d8
merging an lsl #2 that has multiple uses on A9. This shift is free, so there is
no problem merging it in multiple places. Other unprofitable shifts will not be
merged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141247 91177308-0d34-0410-b5e6-96231b3b80d8
This is a first pass at generating the jump table for the sjlj dispatch. It
currently generates something plausible, but hasn't been tested thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141140 91177308-0d34-0410-b5e6-96231b3b80d8
using llvm's public 'C' disassembler API now including annotations.
Hooked this up to Darwin's otool(1) so it can again print things like branch
targets for example this:
blx _puts
instead of this:
blx #-36
and includes support for annotations for branches to symbol stubs like:
bl 0x40 @ symbol stub for: _puts
and annotations for pc relative loads like this:
ldr r3, #8 @ literal pool for: Hello, world!
Also again can print the expression encoded in the Mach-O relocation entries for
things like this:
movt r0, :upper16:((_foo-_bar)+1234)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141129 91177308-0d34-0410-b5e6-96231b3b80d8
This code will replace the version in ARMAsmPrinter.cpp. It creates a new
machine basic block, which is the dispatch for the return from a longjmp
call. It then shoves the address of that machine basic block into the correct
place in the function context so that the EH runtime will jump to it directly
instead of having to go through a compare-and-jump-to-the-dispatch bit. This
should be more efficient in the common case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141031 91177308-0d34-0410-b5e6-96231b3b80d8
It's documented as a separate instruction to line up with the Thumb1
encodings, for which it really is a distinct instruction encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141020 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a couple of Create methods to the ARMConstantPoolConstant class,
* Add its own version of getExistingMachineCPValue, and
* Modify hasSameValue to return false if the object isn't an ARMConstantPoolConstant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140935 91177308-0d34-0410-b5e6-96231b3b80d8
useful if an optimization assumes the stack has been realigned. Credit to
Eli for his assistance.
rdar://10043857
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140924 91177308-0d34-0410-b5e6-96231b3b80d8
This uses less memory and it reduces the complexity of sub-class
operations:
- hasSubClassEq() and friends become O(1) instead of O(N).
- getCommonSubClass() becomes O(N) instead of O(N^2).
In the future, TableGen will infer register classes. This makes it
cheap to add them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140898 91177308-0d34-0410-b5e6-96231b3b80d8
Remove an assert that was expecting only the relevant 16bit portion for
the fixup being handled. Also kill some dead code in the T2 portion.
rdar://9653509
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140861 91177308-0d34-0410-b5e6-96231b3b80d8
Encode the immediate into its 8-bit form as part of isel rather than later,
which simplifies things for mapping the encoding bits, allows the removal
of the custom disassembler decoding hook, makes the operand printer trivial,
and prepares things more cleanly for handling these in the asm parser.
rdar://10211428
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140834 91177308-0d34-0410-b5e6-96231b3b80d8
This is used when we want to take the address of a machine basic block, but it's
not associated with a BB in LLVM IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140823 91177308-0d34-0410-b5e6-96231b3b80d8
Build on previous patches to successfully distinguish between an M-series and A/R-series MSR and MRS instruction. These take different mask names and have a *slightly* different opcode format.
Add decoder and disassembler tests.
Improvement on the previous patch - successfully distinguish between valid v6m and v7m masks (one is a subset of the other). The patch had to be edited slightly to apply to ToT.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140696 91177308-0d34-0410-b5e6-96231b3b80d8
current IR-level pass.
The old SjLj EH pass has some problems, especially with the new EH model. Most
significantly, it violates some of the new restrictions the new model has. For
instance, the 'dispatch' table wants to jump to the landing pad, but we cannot
allow that because only an invoke's unwind edge can jump to a landing pad. This
requires us to mangle the code something awful. In addition, we need to keep the
now dead landingpad instructions around instead of CSE'ing them because the
DWARF emitter uses that information (they are dead because no control flow edge
will execute them - the control flow edge from an invoke's unwind is superceded
by the edge coming from the dispatch).
Basically, this pass belongs not at the IR level where SSA is king, but at the
code-gen level, where we have more flexibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140646 91177308-0d34-0410-b5e6-96231b3b80d8
Math is hard, and isScaledConstantInRange() always returned false for
negative constants. It was doing unsigned division of negative numbers
before casting back to signed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140425 91177308-0d34-0410-b5e6-96231b3b80d8
This is still a hack until we can teach tblgen to generate the
optional CPSR operand rather than an implicit CPSR def. But the
strangeness is now limited to the selection DAG. ADD/SUB MI's no
longer have implicit CPSR defs, nor do we allow flag setting variants
of these opcodes in machine code. There are several corner cases to
consider, and getting one wrong would previously lead to nasty
miscompilation. It's not the first time I've debugged one, so this
time I added enough verification to ensure it won't happen again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140228 91177308-0d34-0410-b5e6-96231b3b80d8
