maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

Fix another problem with ARM constant pools. Radar 7303551. 

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
This commit is contained in:
Bob Wilson 2009-10-15 05:10:36 +00:00
parent c855b45b78
commit b4f2a85fe4
1 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
llvm/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");