summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove extra header.Eric Christopher2010-08-181-1/+0
| | | | llvm-svn: 111456
* Make sure ARM constant island pass does not break up an IT block. If the ↵Evan Cheng2010-08-121-3/+20
| | | | | | 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
* Change -prefer-32bit-thumb to attribute -mattr=+32bit instead to disable ↵Evan Cheng2010-08-091-1/+1
| | | | | | more 32-bit to 16-bit optimizations. llvm-svn: 110584
* Reapply r110396, with fixes to appease the Linux buildbot gods.Owen Anderson2010-08-061-1/+1
| | | | llvm-svn: 110460
* Revert r110396 to fix buildbots.Owen Anderson2010-08-061-1/+1
| | | | llvm-svn: 110410
* Don't use PassInfo* as a type identifier for passes. Instead, use the ↵Owen Anderson2010-08-051-1/+1
| | | | | | | | address of the static ID member as the sole unique type identifier. Clean up APIs related to this change. llvm-svn: 110396
* Revert 109076. It is wrong and was causing regressions. Add someDale Johannesen2010-07-231-18/+48
| | | | | | | | | | 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
* eliminate the TargetInstrInfo::GetInstSizeInBytes hook. Chris Lattner2010-07-221-2/+2
| | | | | | | | 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
* Fix constant island pass's handling of tBR_JTr. The offset of the ↵Evan Cheng2010-07-221-2/+10
| | | | | | | | | | | | | 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
* grammarJim Grosbach2010-07-071-1/+1
| | | | llvm-svn: 107831
* Handle cases where the post-RA scheduler may move instructions between theJim Grosbach2010-07-071-6/+21
| | | | | | | | | address calculation instructions leading up to a jump table when we're trying to convert them into a TB[H] instruction in Thumb2. This realistically shouldn't happen much, if at all, for well formed inputs, but it's more correct to handle it. rdar://7387682 llvm-svn: 107830
* grammar and trailing whitespaceJim Grosbach2010-07-071-6/+6
| | | | llvm-svn: 107811
* Use pre-increment instead of post-increment when the result is not used.Dan Gohman2010-06-221-6/+6
| | | | llvm-svn: 106542
* early exit for dbg_value instructionsJim Grosbach2010-06-211-0/+2
| | | | llvm-svn: 106430
* Clean up 80 column violations. No functional change.Jim Grosbach2010-06-021-1/+2
| | | | llvm-svn: 105350
* use DebugLoc default ctor instead of DebugLoc::getUnknownLoc()Chris Lattner2010-04-021-11/+8
| | | | llvm-svn: 100214
* Change ARM ld/st multiple instructions to have variant instructions forBob Wilson2010-03-131-4/+3
| | | | | | | | | | | | | | | writebacks to the address register. This gets rid of the hack that the first register on the list was the magic writeback register operand. There was an implicit constraint that if that operand was not reg0 it had to match the base register operand. The post-RA scheduler's antidependency breaker did not understand that constraint and sometimes changed one without the other. This also fixes Radar 7495976 and should help the verifier work better for ARM code. There are now new ld/st instructions explicit writeback operands and explicit constraints that tie those registers together. llvm-svn: 98409
* move target-independent opcodes out of TargetInstrInfoChris Lattner2010-02-091-1/+1
| | | | | | | | | into TargetOpcodes.h. #include the new TargetOpcodes.h into MachineInstr. Add new inline accessors (like isPHI()) to MachineInstr, and start using them throughout the codebase. llvm-svn: 95687
* eliminate the ARMFunctionInfo::Align member, using Chris Lattner2010-01-271-5/+5
| | | | | | MachineFunction::Alignment instead. llvm-svn: 94701
* prep work to support a future where getJumpTableInfo will returnChris Lattner2010-01-251-0/+4
| | | | | | | a null pointer for functions with no jump tables. No functionality change. llvm-svn: 94469
* improve portability to avoid conflicting with std::next in c++'0x.Chris Lattner2009-12-031-11/+11
| | | | | | Patch by Howard Hinnant! llvm-svn: 90365
* The verify() call of CPEIsInRange() isn't right for the assertion check ofJim Grosbach2009-11-201-2/+5
| | | | | | | | | | constant pool ranges, as CPEIsInRange() makes conservative assumptions about the potential alignment changes from branch adjustments. The verification, on the other hand, runs after those branch adjustments are made, so the effects on alignment are known and already taken into account. The sanity check in verify should check the range directly instead. llvm-svn: 89473
* Remove verifySizes() since it's not adding much value.Jim Grosbach2009-11-201-36/+0
| | | | llvm-svn: 89443
* When placing constant islands and adjusting for alignment padding, inlineJim Grosbach2009-11-191-7/+66
| | | | | | | | | | | assembly can confuse things utterly, as it's assumed that instructions in inline assembly are 4 bytes wide. For Thumb mode, that's often not true, so the calculations for when alignment padding will be present get thrown off, ultimately leading to out of range constant pool entry references. Making more conservative assumptions that padding may be necessary when inline asm is present avoids this situation. llvm-svn: 89403
* fix typoJim Grosbach2009-11-191-1/+1
| | | | llvm-svn: 89369
* Enable arm jumpt table adjustment.Jim Grosbach2009-11-171-1/+1
| | | | llvm-svn: 89143
* When moving a block for table jumps, make sure the prior block terminatorJim Grosbach2009-11-171-7/+9
| | | | | | | is analyzable so it can be updated. If it's not, be safe and don't move the block. llvm-svn: 89022
* Simplify thumb2 jump table adjustments. Remove unnecessary calculation andJim Grosbach2009-11-161-58/+14
| | | | | | usage of block sizes and offsets. llvm-svn: 88935
* clarify commentJim Grosbach2009-11-161-2/+2
| | | | llvm-svn: 88933
* back off for a bit. tracking down weirdnessJim Grosbach2009-11-161-1/+1
| | | | llvm-svn: 88919
* Analyze has to be before checking the condition, obviously. Properly ↵Jim Grosbach2009-11-161-6/+8
| | | | | | construct an iterator for prior. llvm-svn: 88917
* cleanup.Jim Grosbach2009-11-141-3/+1
| | | | llvm-svn: 88812
* Cleanup flow, and only update the jump table we're analyzing when replacing ↵Jim Grosbach2009-11-141-9/+11
| | | | | | a destination MBB. llvm-svn: 88805
* Block renumberingJim Grosbach2009-11-131-3/+1
| | | | llvm-svn: 87056
* Update TB[BH] layout optimization. Add support for moving the target blockJim Grosbach2009-11-121-33/+115
| | | | | | | to directly follow the jump table. Move the layout changes to prior to any constant island handling. llvm-svn: 86999
* Revert 86857. It's causing consumer-typeset to fail, and there's a better ↵Jim Grosbach2009-11-121-7/+4
| | | | | | way to do it forthcoming anyway. llvm-svn: 86945
* Do jump table adjustment before constant island allocationJim Grosbach2009-11-111-4/+7
| | | | llvm-svn: 86857
* The TBB and TBH instructions for Thumb2 are really handy for jump tables, butJim Grosbach2009-11-111-3/+96
| | | | | | | | | | | can only branch forward. To best take advantage of them, we'd like to adjust the basic blocks around a bit when reasonable. This patch puts basics in place to do that, with a super-simple algorithm for backwards jump table targets that creates a new branch after the jump table which branches backwards. Real heuristics for reordering blocks or other modifications rather than inserting branches will follow. llvm-svn: 86791
* Use Unified Assembly Syntax for the ARM backend.Jim Grosbach2009-11-091-2/+2
| | | | llvm-svn: 86494
* Use cbz and cbnz instructions.Evan Cheng2009-10-311-11/+53
| | | | llvm-svn: 85698
* Remove includes of Support/Compiler.h that are no longer needed after theNick Lewycky2009-10-251-1/+0
| | | | | | VISIBILITY_HIDDEN removal. llvm-svn: 85043
* Remove VISIBILITY_HIDDEN from class/struct found inside anonymous namespaces.Nick Lewycky2009-10-251-1/+1
| | | | | | | Chris claims we should never have visibility_hidden inside any .cpp file but that's still not true even after this commit. llvm-svn: 85042
* Fix a potential performance problem in placing ARM constant pools.Bob Wilson2009-10-151-29/+67
| | | | | | | | | | | | In the case where there are no good places to put constants and we fall back upon inserting unconditional branches to make new blocks, allow all constant pool references in range of those blocks to put constants there, even if that means resetting the "high water marks" for those references. This will still terminate because you can't keep splitting blocks forever, and in the bad cases where we have to split blocks, it is important to avoid splitting more than necessary. llvm-svn: 84202
* Be smarter about reusing constant pool entries.Bob Wilson2009-10-151-4/+17
| | | | llvm-svn: 84173
* Fix another problem with ARM constant pools. Radar 7303551.Bob Wilson2009-10-151-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | When ARMConstantIslandPass cannot find any good locations (i.e., "water") to place constants, it falls back to inserting unconditional branches to make a place to put them. My recent change exposed a problem in this area. We may sometimes append to the same block more than one unconditional branch. The symptoms of this are that the generated assembly has a branch to an undefined label and running llc with -debug will cause a seg fault. This happens more easily since my change to prevent CPEs from moving from lower to higher addresses as the algorithm iterates, but it could have happened before. The end of the block may be in range for various constant pool references, but the insertion point for new CPEs is not right at the end of the block -- it is at the end of the CPEs that have already been placed at the end of the block. The insertion point could be out of range. When that happens, the fallback code will always append another unconditional branch if the end of the block is in range. The fix is to only append an unconditional branch if the block does not already end with one. I also removed a check to see if the constant pool load instruction is at the end of the block, since that is redundant with checking if the end of the block is in-range. There is more to be done here, but I think this fixes the immediate problem. llvm-svn: 84172
* Fix regression introduced by r83894.Bob Wilson2009-10-131-1/+2
| | | | llvm-svn: 83982
* Delete a comment that makes no sense to me. The statement that moving a CPEBob Wilson2009-10-121-2/+1
| | | | | | | | | before its reference is only supported on ARM has not been true for a while. In fact, until recently, that was only supported for Thumb. Besides that, CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have no effect on Thumb alignment. llvm-svn: 83916
* Change CreateNewWater method to return NewMBB by reference.Bob Wilson2009-10-121-8/+8
| | | | llvm-svn: 83905
* Last week, ARMConstantIslandPass was failing to converge for theBob Wilson2009-10-121-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has since been masked by an unrelated change (just randomly), so I don't have a testcase for this now. Radar 7291928. The situation where this happened is that a constant pool entry (CPE) was placed at a lower address than the load that referenced it. There were in fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were close together in the code. The distance from the loads to the CPEs was right at the limit of what they could handle, so that only one of the CPEs could be placed within range. On every iteration, the first CPE was found to be out of range, causing a new CPE to be inserted. The second CPE had been in range but the newly inserted entry pushed it too far away. Thus the second CPE was also replaced by a new entry, which in turn pushed the first CPE out of range. Etc. Judging from some comments in the code, the initial implementation of this pass did not support CPEs placed _before_ their references. In the case where the CPE is placed at a higher address, the key to making the algorithm terminate is that new CPEs are only inserted at the end of a group of adjacent CPEs. This is implemented by removing a basic block from the "WaterList" once it has been used, and then adding the newly inserted CPE block to the list so that the next insertion will come after it. This avoids the ping-pong effect where CPEs are repeatedly moved to the beginning of a group of adjacent CPEs. This does not work when going backwards, however, because the entries at the end of an adjacent group of CPEs are closer than the CPEs earlier in the group. To make this pass terminate, we need to maintain a property that changes can only happen in some sort of monotonic fashion. The fix used here is to require that the CPE for a particular constant pool load can only move to lower addresses. This is a very simple change to the code and should not cause any significant degradation in the results. llvm-svn: 83902
* Another minor clean-up.Bob Wilson2009-10-121-5/+5
| | | | llvm-svn: 83897
OpenPOWER on IntegriCloud