summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Migrate ARM except for TTI, AsmPrinter, and frame loweringEric Christopher2015-01-291-4/+2
| | | | | | away from getSubtargetImpl. llvm-svn: 227399
* Move DataLayout back to the TargetMachine from TargetSubtargetInfoEric Christopher2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | derived classes. Since global data alignment, layout, and mangling is often based on the DataLayout, move it to the TargetMachine. This ensures that global data is going to be layed out and mangled consistently if the subtarget changes on a per function basis. Prior to this all targets(*) have had subtarget dependent code moved out and onto the TargetMachine. *One target hasn't been migrated as part of this change: R600. The R600 port has, as a subtarget feature, the size of pointers and this affects global data layout. I've currently hacked in a FIXME to enable progress, but the port needs to be updated to either pass the 64-bitness to the TargetMachine, or fix the DataLayout to avoid subtarget dependent features. llvm-svn: 227113
* [ARM] Fix a bug in constant island pass that was triggering an assertion.Akira Hatanaka2015-01-081-1/+1
| | | | | | | | | | | | | | | | | | | The assert was being triggered when the distance between a constant pool entry and its user exceeded the maximally allowed distance after thumb2 branch shortening. A padding was inserted after a thumb2 branch instruction was shrunk, which caused the user to be out of range. This is wrong as the padding should have been inserted by the layout algorithm so that the distance between two instructions doesn't grow later during thumb2 instruction optimization. This commit fixes the code in ARMConstantIslands::createNewWater to call computeBlockSize and set BasicBlock::Unalign when a branch instruction is inserted to create new water after a basic block. A non-zero Unalign causes the worst-case padding to be inserted when adjustBBOffsetsAfter is called to recompute the basic block offsets. rdar://problem/19130476 llvm-svn: 225467
* [ARMConstantIsland] Insert tbb/tbh optimization where previous jump table ↵Chad Rosier2014-12-121-1/+3
| | | | | | resided. llvm-svn: 224165
* ARM: allow constpool entry to be moved to the user's block in all cases.Tim Northover2014-11-131-1/+7
| | | | | | | | | | | | | | | Normally entries can only move to a lower address, but when that wasn't viable, the user's block was considered anyway. Unfortunately, it went via createNewWater which wasn't designed to handle the case where there's already an island after the block. Unfortunately, the test we have is slow and fragile, and I couldn't reduce it to anything sane even with the @llvm.arm.space intrinsic. The test change here is recreating the previous one after the change. rdar://problem/18545506 llvm-svn: 221905
* ARM: avoid duplicating branches during constant islands.Tim Northover2014-11-131-6/+10
| | | | | | | | | We were using a naive heuristic to determine whether a basic block already had an unconditional branch at the end. This mostly corresponded to reality (assuming branches got optimised) because there's not much point in a branch to the next block, but could go wrong. llvm-svn: 221904
* ARM: Fix a bug which was causing convergence failure in constant-island pass.Akira Hatanaka2014-10-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug is in ARMConstantIslands::createNewWater where the upper bound of the new water split point is computed: // This could point off the end of the block if we've already got constant // pool entries following this block; only the last one is in the water list. // Back past any possible branches (allow for a conditional and a maximally // long unconditional). if (BaseInsertOffset + 8 >= UserBBI.postOffset()) { BaseInsertOffset = UserBBI.postOffset() - UPad - 8; DEBUG(dbgs() << format("Move inside block: %#x\n", BaseInsertOffset)); } The split point is supposed to be somewhere between the machine instruction that loads from the constant pool entry and the end of the basic block, before branch instructions. The code above is fine if the basic block is large enough and there are a sufficient number of instructions following the machine instruction. However, if the machine instruction is near the end of the basic block, BaseInsertOffset can point to the machine instruction or another instruction that precedes it, and this can lead to convergence failure. This commit fixes this bug by ensuring BaseInsertOffset is larger than the offset of the instruction following the constant-loading instruction. rdar://problem/18581150 llvm-svn: 220015
* Eliminate some deep std::vector copies. NFC.Benjamin Kramer2014-10-031-3/+1
| | | | llvm-svn: 218999
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-1/+1
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+4
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-9/+9
| | | | llvm-svn: 207197
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | definition below all of the header #include lines, lib/Target/... edition. llvm-svn: 206842
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-101-2/+2
| | | | | | class. llvm-svn: 203433
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-13/+12
| | | | | | Remove the old functions. llvm-svn: 202636
* ARM: Fix crash in ARM backend inside of ARMConstantIslandPassDavid Majnemer2013-06-041-0/+1
| | | | | | | | | | The ARM backend did not expect LDRBi12 to hold a constant pool operand. Allow for LLVM to deal with the instruction similar to how it deals with LDRi12. This fixes PR16215. llvm-svn: 183238
* Replace Count{Leading,Trailing}Zeros_{32,64} with count{Leading,Trailing}Zeros.Michael J. Spencer2013-05-241-1/+1
| | | | llvm-svn: 182680
* Radar numbers don't belong in source code.Evan Cheng2013-02-211-1/+1
| | | | llvm-svn: 175775
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-7/+7
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Move TargetData to DataLayout.Micah Villmow2012-10-081-2/+2
| | | | llvm-svn: 165402
* Reduce duplicated hash map lookups.Benjamin Kramer2012-08-221-3/+2
| | | | llvm-svn: 162362
* Fix the naming of ensureAlignment. Per the coding standard function namesChad Rosier2012-07-061-3/+3
| | | | | | should be camel case, and start with a lower case letter. llvm-svn: 159877
* Fix address calculation error from r155744.Jakob Stoklund Olesen2012-04-301-1/+6
| | | | | | | | | | | | This was exposed by SingleSource/UnitTests/Vector/constpool.c. The computed size of a basic block isn't always a multiple of its known alignment, and that can introduce extra alignment padding after the block. <rdar://problem/11347135> llvm-svn: 155845
* Fix a problem with blocks that need to be split twice.Jakob Stoklund Olesen2012-04-281-3/+5
| | | | | | | | | The code could search past the end of the basic block when there was already a constant pool entry after the block. Test case with giant basic block in SingleSource/UnitTests/Vector/constpool.c llvm-svn: 155753
* Track worst case alignment padding more accurately.Jakob Stoklund Olesen2012-04-271-42/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, ARMConstantIslandPass would conservatively compute the address of an aligned basic block as: RoundUpToAlignment(Offset + UnknownPadding) This worked fine for the layout algorithm itself, but it could fool the verify() function because it accounts for alignment padding twice: Once when adding the worst case UnknownPadding, and again by rounding up the fictional block offset. This meant that when optimizeThumb2Instructions would shrink an instruction, the conservative distance estimate could grow. That shouldn't be possible since the woorst case alignment padding wss already included. This patch drops the use of RoundUpToAlignment, and depends only on worst case padding to compute conservative block offsets. This has the weird effect that the computed offset for an aligned block may not be aligned. The important difference is that shrinking an instruction can never cause the estimated distance between two instructions to grow. The estimated distance is always larger than the real distance that only the assembler knows. <rdar://problem/11339352> llvm-svn: 155744
* Add a 2 byte safety margin in offset computations.Jakob Stoklund Olesen2012-03-311-2/+5
| | | | | | | | | | | | ARMConstantIslandPass still has bugs where jump table compression can cause constant pool entries to go out of range. Add a safety margin of 2 bytes when placing constant islands, but use the real max displacement for verification. <rdar://problem/11156595> llvm-svn: 153789
* Add more debugging output to ARMConstantIslandPass.Jakob Stoklund Olesen2012-03-311-2/+16
| | | | llvm-svn: 153788
* Invalidate liveness in ARMConstantIslandPass.Jakob Stoklund Olesen2012-03-291-0/+4
| | | | | | | | | | This pass splits basic blocks to insert constant islands, and it doesn't recompute the live-in lists. No later passes depend on accurate liveness information. This fixes PR12410 where the machine code verifier was complaining. llvm-svn: 153700
* Remove unnecessary llvm:: qualificationsCraig Topper2012-03-271-3/+3
| | | | llvm-svn: 153500
* Replace uses of ARMBaseInstrInfo and ARMTargetMachine with the Base versions.Craig Topper2012-03-251-3/+2
| | | | llvm-svn: 153421
* ARM tidy up ARMConstantIsland.cpp.Jim Grosbach2012-03-231-156/+158
| | | | | | No functional change, just tidy up the code and nomenclature a bit. llvm-svn: 153347
* Refactor loop for better readability.Jim Grosbach2012-01-311-3/+2
| | | | | | Excellent suggestion from Ben Kramer. llvm-svn: 149417
* Add explanatory comment.Jim Grosbach2012-01-311-0/+1
| | | | llvm-svn: 149416
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-1/+0
| | | | llvm-svn: 148578
* After r147827 and r147902, it's now possible for unallocatable registers to beEvan Cheng2012-01-141-0/+5
| | | | | | | | | | | | | | | | | | | live across BBs before register allocation. This miscompiled 197.parser when a cmp + b are optimized to a cbnz instruction even though the CPSR def is live-in a successor. cbnz r6, LBB89_12 ... LBB89_12: ble LBB89_1 The fix consists of two parts. 1) Teach LiveVariables that some unallocatable registers might be liveouts so don't mark their last use as kill if they are. 2) ARM constantpool island pass shouldn't form cbz / cbnz if the conditional branch does not kill CPSR. rdar://10676853 llvm-svn: 148168
* Consider unknown alignment caused by OptimizeThumb2Instructions().Jakob Stoklund Olesen2012-01-101-4/+25
| | | | | | | | | | | | | | | | | | | | This function runs after all constant islands have been placed, and may shrink some instructions to their 2-byte forms. This can actually cause some constant pool entries to move out of range because of growing alignment padding. Treat instructions that may be shrunk the same as inline asm - they erode the known alignment bits. Also reinstate an old assertion in verify(). It is correct now that basic block offsets include alignments. Add a single large test case that will hopefully exercise many parts of the constant island pass. <rdar://problem/10670199> llvm-svn: 147885
* Accurately model hardware alignment rounding.Jakob Stoklund Olesen2012-01-101-21/+56
| | | | | | | | | | | | | | | | | | | On Thumb, the displacement computation hardware uses the address of the current instruction rouned down to a multiple of 4. Include this rounding in the UserOffset we compute for each instruction. When inline asm is present, the instruction alignment may not be known. Constrain the maximum displacement instead in that case. This makes it possible for CreateNewWater() and OffsetIsInRange() to agree about the valid displacements. When they disagree, infinite looping happens. As always, test cases for this stuff are insane. <rdar://problem/10660175> llvm-svn: 147825
* Catch runaway ARMConstantIslandPass even in -Asserts builds.Jakob Stoklund Olesen2012-01-091-2/+2
| | | | | | | | | The pass is prone to looping, and it is better to crash than loop forever, even in a -Asserts build. <rdar://problem/10660175> llvm-svn: 147806
* Abort AdjustBBOffsetsAfter early when possible.Jakob Stoklund Olesen2012-01-061-2/+10
| | | | llvm-svn: 147685
* Fix off-by-one error in bucket sort.Jakob Stoklund Olesen2011-12-161-1/+1
| | | | | | | | | The bad sorting caused a misaligned basic block when building 176.vpr in ARM mode. <rdar://problem/10594653> llvm-svn: 146767
* Don't adjust for alignment padding in OffsetIsInRange.Jakob Stoklund Olesen2011-12-161-16/+1
| | | | | | | | | | | This adjustment is already included in the block offsets computed by BasicBlockInfo, and adjusting again here can cause the pass to loop. When CreateNewWater splits a basic block, OffsetIsInRange would reject the new CPE on the next pass because of the too conservative alignment adjustment. This caused the block to be split again, and so on. llvm-svn: 146751
* Note ARM constant island alignment in the release notes.Jakob Stoklund Olesen2011-12-161-0/+1
| | | | | | | | The command line option should be removed, but not until the feature has gotten a lot of testing. The ARMConstantIslandPass tends to have subtle bugs that only show up after a while. llvm-svn: 146739
* Enable proper constant island alignment by default.Jakob Stoklund Olesen2011-12-151-1/+1
| | | | | | | The code size increase is tiny (< 0.05%) because so little code uses 16-byte constant pool entries. llvm-svn: 146690
* Consider CPE alignment in CreateNewWater().Jakob Stoklund Olesen2011-12-141-104/+117
| | | | | | | | | | | An aligned constant pool entry may require extra alignment padding where the new water is created. Take that into account when computing offset. Also consider the alignment of other constant pool entries when splitting a basic block. Alignment padding may make it necessary to move the split point higher. llvm-svn: 146609
* Fix speling and 80-col.Jakob Stoklund Olesen2011-12-141-4/+3
| | | | llvm-svn: 146575
* Account for CPE alignment when searching for new water.Jakob Stoklund Olesen2011-12-131-31/+51
| | | | | | | | | | | Constant pool entries with different alignment may cause more alignment padding to be inserted. Compute the amount of padding needed, and try to pick the location that requires the least amount of padding. Also take the extra padding into account when the water is above the use. llvm-svn: 146458
* Add a postOffset() alignment argument.Jakob Stoklund Olesen2011-12-121-14/+15
| | | | | | | This computes the offset of the layout sucessor block, considering its alignment as well. llvm-svn: 146401
* Fix typo.Jakob Stoklund Olesen2011-12-121-1/+1
| | | | llvm-svn: 146400
* Also set the proper alignment on inner islands and the function itself.Jakob Stoklund Olesen2011-12-121-15/+29
| | | | | | | | | Downgrade the alignment of the initial constant island when constant pool entries are moved elsewhere. This is all gated by -arm-align-constant-islands. llvm-svn: 146391
* Make MF a class member instead of passing it around everywhere.Jakob Stoklund Olesen2011-12-121-81/+77
| | | | | | | | Also add an MCP member pointing to the machine constant pool. No functional change intended. llvm-svn: 146382
OpenPOWER on IntegriCloud