RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-12-14 07:31:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Fix another problem with ARM constant pools. Radar 7303551.

Browse Source 
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84172 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Bob Wilson 2009-10-15 05:10:36 +00:00
parent 2ee743b53b
commit 36fa5321ba
1 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
lib/Target/ARM/ARMConstantIslandPass.cpp
View File

@ -1006,14 +1006,12 @@ void ARMConstantIslands::CreateNewWater(unsigned CPUserIndex,
BBSizes[UserMBB->getNumber()];
assert(OffsetOfNextBlock== BBOffsets[UserMBB->getNumber()+1]);
// If the use is at the end of the block, or the end of the block
// is within range, make new water there. (The addition below is
// for the unconditional branch we will be adding: 4 bytes on ARM + Thumb2,
// 2 on Thumb1. Possible Thumb1 alignment padding is allowed for
// If the block does not end in an unconditional branch already, and if the
// end of the block is within range, make new water there. (The addition
// below is for the unconditional branch we will be adding: 4 bytes on ARM +
// Thumb2, 2 on Thumb1. Possible Thumb1 alignment padding is allowed for
// inside OffsetIsInRange.
// If the block ends in an unconditional branch already, it is water,
// and is known to be out of range, so we'll always be adding a branch.)
if (&UserMBB->back() == UserMI ||
if (BBHasFallthrough(UserMBB) &&
OffsetIsInRange(UserOffset, OffsetOfNextBlock + (isThumb1 ? 2: 4),
U.MaxDisp, U.NegOk, U.IsSoImm)) {
DEBUG(errs() << "Split at end of block\n");