Fix another problem with ARM constant pools. Radar 7303551.
authorBob Wilson <bob.wilson@apple.com>
Thu, 15 Oct 2009 05:10:36 +0000 (05:10 +0000)
committerBob Wilson <bob.wilson@apple.com>
Thu, 15 Oct 2009 05:10:36 +0000 (05:10 +0000)
commit36fa5321bacf351f47d6193f56c464e6ab93b934
tree6ec21ea00b8614df683f5ee7787d6c08e3e1fa74
parent2ee743b53b32ffc57739abc83667a0c15bb43a71
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84172 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/ARM/ARMConstantIslandPass.cpp