[llvm-commits] [llvm] r89403 - /llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp

[Jim Grosbach]

On Nov 22, 2009, at 6:00 AM, Chris Lattner wrote:

>
> On Nov 19, 2009, at 3:10 PM, Jim Grosbach wrote:
>
>> Author: grosbach
>> Date: Thu Nov 19 17:10:28 2009
>> New Revision: 89403
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=89403&view=rev
>> Log:
>> When placing constant islands and adjusting for alignment padding,  
>> inline
>> 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.
>
> Are you sure that this is the right thing to do?  GCC inline asm  
> precisely specifies how the size of an inline asm is computed:
> http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm  
> (6.39.1)
>
> If some inline asm isn't working with this algorithm, then the  
> inline asm is wrong and should be fixed.


Yes, I believe this is the correct approach.

The algorithm described is, "The estimate is formed by counting the  
number of statements in the pattern of the asm and multiplying that by  
the length of the longest instruction on that processor." This is  
exactly what we do, and gets us close, but it is still an estimate. To  
do better, we'll need to actually parse the assembly code to determine  
whether it's a 16 or a 32 bit instruction. In Thumb2, that's a non- 
trivial thing, and I suspect we don't want to go down that path, at  
least right now.

What's happening here is that the inline asm is actually shorter than  
the estimate since it's a 16-bit instruction, and is also not located  
between the constant pool reference and the constant pool entry. Since  
it's different in size than what the estimate believes, our  
calculations for when alignment padding will be inserted are now off,  
leading to problems.

This patch adjusts those padding calculations to know that in the  
presence of inline assembly, we're dealing with an estimate and  
therefore can't make assumptions about alignment padding.

-Jim