| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Order constant pool entries by descending alignment in the initial
island to ensure packing and correct alignment. When the command line
flag is set, also align the basic block containing the constant pool
entries.
This is only a partial implementation of constant island alignment. More
to come.
llvm-svn: 146375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The split point is picked such that the newly created water has the same
alignment as the function. This makes the island suitable for constant
pool entries with potentially higher alignment.
This also fixes an issue where the basic block was split one instruction
too late, causing nonconvergence of the algorithm.
<rdar://problem/10550705>
There is still an issue with correctly packing differently aligned
entries in the island.
llvm-svn: 146314
|
|
|
|
| |
llvm-svn: 146313
|
|
|
|
| |
llvm-svn: 146270
|
|
|
|
| |
llvm-svn: 146264
|
|
|
|
|
|
|
|
|
|
| |
It is not used any more. We are tracking inline assembly misalignments
directly through the BBInfo.Unalign and KnownBits fields.
A simple conservative size estimate is not good enough since it can
cause alignment padding to be underestimated.
llvm-svn: 146124
|
|
|
|
| |
llvm-svn: 146121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compute alignment padding before and after basic blocks dynamically.
Heed basic block alignment.
This simplifies bookkeeping because we don't have to constantly add and
remove padding from BBInfo.Size. It also makes it possible to track the
extra known alignment bits we get after a tBR_JTr terminator and when
entering an aligned basic block.
This makes the ARMConstantIslandPass aware of aligned basic blocks.
It is tricky to model block alignment correctly when dealing with inline
assembly and tBR_JTr instructions that have variable size. If inline
assembly turns out to be smaller than expected, that may cause following
alignment padding to be larger than expected. This could cause constant
pool entries to move out of range.
To avoid that problem, we use the worst case alignment padding following
inline assembly. This may cause slightly suboptimal constant island
placement in aligned basic blocks following inline assembly. Normal
functions should be unaffected.
llvm-svn: 146118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
llvm-svn: 146026
|
|
|
|
|
|
|
|
|
| |
The block offset can be computed from the previous block. That is more
robust than keeping track of a delta.
Eliminate one redundant AdjustBBOffsetsAfter call.
llvm-svn: 146018
|
|
|
|
|
|
| |
These fields are not used for anything yet.
llvm-svn: 146017
|
|
|
|
| |
llvm-svn: 146008
|
|
|
|
|
|
| |
No functional change is intended.
llvm-svn: 146005
|
|
|
|
|
|
| |
This caused more offset errors.
llvm-svn: 145980
|
|
|
|
|
|
|
|
|
|
| |
This pseudo-instruction contains a .align directive in its expansion, so
the total size may vary by 2 bytes.
It is too difficult to accurately keep track of this alignment
directive, just use the worst-case size instead.
llvm-svn: 145971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARMConstantIslandPass may sometimes leave empty constant islands behind
(it really shouldn't). Remove the alignment from the empty islands so
the size calculations are still correct.
This should fix the many Thumb1 assembler errors in the nightly test
suite.
The reduced test case for this problem is way too big. That is to be
expected for ARMConstantIslandPass bugs.
<rdar://problem/10534709>
llvm-svn: 145970
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all ARM::CONSTPOOL_ENTRY instructions had a hardwired
alignment of 4 bytes emitted by ARMAsmPrinter. Now the same alignment
is set on the basic block.
This is in preparation of supporting ARM constant pool islands with
different alignments.
llvm-svn: 145890
|
|
|
|
| |
llvm-svn: 145883
|
|
|
|
|
|
| |
a tBfar now. Fixes nightly test failures on armv6 Thumb. <rdar://problem/10110404>
llvm-svn: 139531
|
|
|
|
|
|
| |
manually create ARM::tB.
llvm-svn: 139429
|
|
|
|
|
|
| |
have a predicate operand, unlike conditional branches.
llvm-svn: 139415
|
|
|
|
|
|
| |
ARM MC code from target.
llvm-svn: 135636
|
|
|
|
|
|
| |
Original Log: Get rid of the separate opcodes for the Darwin versions of tBL, tBLXi, and tBLXr, using pseudo-instructions to lower to the single final opcode. Update the ARM disassembler for this change.
llvm-svn: 135414
|
|
|
|
|
|
|
|
|
|
| |
The normal tBX instruction is predicable, so there's no reason the
pseudos for using it as a return shouldn't be. Gives us some nice code-gen
improvements as can be seen by the test changes. In particular, several
tests now have to disable if-conversion because it works too well and defeats
the test.
llvm-svn: 134746
|
|
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
|
|
|
|
|
| |
possible. rdar://9216009
llvm-svn: 128743
|
|
|
|
| |
llvm-svn: 125563
|
|
|
|
|
|
| |
(which worked around it). This should get us back to the old, correct behavior, though it will make the integrated assembler unhappy for the time being.
llvm-svn: 125127
|
|
|
|
|
|
|
|
|
|
|
|
| |
t2LDRpci with t2LDRi12.
There are a couple of problems with this.
1. The encoding for the literal and immediate constant are different.
Note bit 7 of the literal case is 'U' so it can be negative.
2. t2LDRi12 is now narrowed to tLDRpci before constant island pass is run.
So we end up never using the Thumb2 instruction, which ends up creating a
lot more constant islands.
llvm-svn: 125074
|
|
|
|
| |
llvm-svn: 124570
|
|
|
|
|
|
|
|
|
|
|
|
| |
movw r0, :lower16:(L_foo$non_lazy_ptr-(LPC0_0+4))
movt r0, :upper16:(L_foo$non_lazy_ptr-(LPC0_0+4))
LPC0_0:
add r0, pc, r0
It's not yet enabled by default as some tests are failing. I suspect bugs in
down stream tools.
llvm-svn: 123619
|
|
|
|
| |
llvm-svn: 122302
|
|
|
|
| |
llvm-svn: 122129
|
|
|
|
|
|
| |
Canonicalize on tLDRpci and remove tLDRcp.
llvm-svn: 121920
|
|
|
|
| |
llvm-svn: 121726
|
|
|
|
|
|
|
|
| |
Provide correct fixups for Thumb2 ADR,
which is _of course_ different from ARM ADR fixups, or any other Thumb2 fixup.
llvm-svn: 121721
|
|
|
|
|
|
|
| |
possible. They were duplicates for everything exception the source pattern
before.
llvm-svn: 121179
|
|
|
|
|
|
| |
gazillion places that need to know about it.
llvm-svn: 121082
|
|
|
|
|
|
| |
data. Next up, pseudo-izing them.
llvm-svn: 120320
|
|
|
|
|
|
|
|
| |
explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.
llvm-svn: 117409
|
|
|
|
| |
llvm-svn: 111456
|
|
|
|
|
|
| |
split point is in the middle of an IT block, it should move it up to just above the IT instruction. rdar://8302637
llvm-svn: 110947
|
|
|
|
|
|
| |
more 32-bit to 16-bit optimizations.
llvm-svn: 110584
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110410
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
|
|
|
|
|
|
| |
comments explaining why it was wrong. 8225024.
Fix the real problem in 8213383: the code that splits very large
blocks when no other place to put constants can be found was not
considering the case that the block contained a Thumb tablejump.
llvm-svn: 109282
|
|
|
|
|
|
|
|
| |
ARM/PPC/MSP430-specific code (which are the only targets that
implement the hook) can directly reference their target-specific
instrinfo classes.
llvm-svn: 109171
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction does not have to be 4-byte aligned. Rather, it's the offset + 2 that must be aligned since the instruction expands into:
mov pc, r1
.align 2
LJTI0_0_0:
.long LBB0_14
This fixes rdar://8213383. No test case since it's not possible to come up with a suitable small one.
llvm-svn: 109076
|
|
|
|
| |
llvm-svn: 107831
|