llvm dev - Aug 2010 - [LLVMdev] ToT ARM Code generator causing - Error: invalid constant (xxx) after fixup in assembly output

On 8/18/2010 12:39 PM, Dale Johannesen wrote:
> I can look at this, but you'll need to send the .bc file.  Please open 
> a PR?
I would do it but I am in  a bit of a pickle as the .bc is from 
propriety code and
I can  not post it.
Anyway, I have been trying to re-create the problem in a simpler test case.
Since, I do not have access to the source for the .bc I am trying to guess
the kind of code that created the problem. So far I was able to replicate
the one large basic block but I not sure how to produce the constant pool
with the jumptable like in the description below.
>
> There have been lots of bugs in ARMConstantIslands where it's off by 
> 1, but I haven't seen one where it's off by a lot like this.
The big offset is due to this one large basic block and is not a problem 
with alignment or any off by 1  issue.
>
> On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote:
>
>> Hello,
>>
>> This problem happens in ToT under specific conditions - namely there is
>> a big BB#671 basic block of code
>> the just copies data from memory location to another. At the beginning
>> of BBB#671 r0 is loaded
>> from the jumptable in the constant pool immediately after it.
>> Displacement from the pc
>> in this case is #1476 which is way above magic #1020 hence the error
>> after fixup.
>> Both ARMCodeEmitter::emitLEApcrelJTInstruction() and 
>> emitJumpTableAddress()
>> are responsible for the offending instruction adr    r0, #.LJTI8485_1_1
>> But besides the fact that they do not complain about the invalid offset
>> from the pc I do not see
>> anything wrong here.
>>
>> The problem seems to be in the ARMConstantIslands which is not
splitting
>> BB#671 into
>> smaller pieces and thus producing over the limit 'add' opcode.
>>
>> This code fragment below is produced from a rather large bitcode file
>> that resists being reduced to something
>> more manageable. As a result keystrokes in gdb are very "expensive
" and
>> taxing my  machine rather heavily.
>>
>> Any thoughts and hints on debugging this issue would be much 
>> appreciated!
>>
>> I have used  llc with these options to produce the output:
>>
>> llc -O0 -regalloc=fast  -relocation-model=pic  l.bc -o ll-2.8.s
>>
>>     bhi    .LBB8485_455
>> @ BB#671:                               @ %bb154
>>                                         @   in Loop: Header=BB8485_1112
>> Depth=5
>>     adr    r0, #.LJTI8485_1_1
>>     ldr    r1, [sp, #3300]
>>     ldr    r2, [r0, r1, lsl #2]
>>     ...
>>     lots of boring code omitted
>>     ...
>>     add    pc, r2, r0
>> .LJTI8485_1_1:
>>     .set    .L8485_1_1_set_70,.LBB8485_70-.LJTI8485_1_1
>>     .long     .L8485_1_1_set_70
>>     .set    .L8485_1_1_set_49,.LBB8485_49-.LJTI8485_1_1
>>     .long     .L8485_1_1_set_49
>>     .set    .L8485_1_1_set_419,.LBB8485_419-.LJTI8485_1_1
>>     .long     .L8485_1_1_set_419
>>     .set    .L8485_1_1_set_1085,.LBB8485_1085-.LJTI8485_1_1
>>     .long     .L8485_1_1_set_1085
>>     .set    .L8485_1_1_set_439,.LBB8485_439-.LJTI8485_1_1
>>
>> When assembler runs on the output we get:
>>
>> ll-2.8.s:1916640: Error: invalid constant (5c4) after fixup
>>
>> Standard disclaimer:
>> All of the tools used were proper ARM cross compiler,assembler, etc
>> running on x86_64
>> and no bitcode was ever harmed during debugging.
>>
>> Cheers,
>> Pawel
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote:
> On 8/18/2010 12:39 PM, Dale Johannesen wrote:
>> I can look at this, but you'll need to send the .bc file.  Please  
>> open a PR?
>
> I would do it but I am in  a bit of a pickle as the .bc is from  
> propriety code and
> I can  not post it.
Can't help much then.  You might look into obfuscating the code, some  
companies are OK with distributing obfuscated IR.
-debug-only=arm-cp-islands will show you what ARMConstantIslands is  
thinking pretty well.
> Anyway, I have been trying to re-create the problem in a simpler  
> test case.
> Since, I do not have access to the source for the .bc I am trying to  
> guess
> the kind of code that created the problem. So far I was able to  
> replicate
> the one large basic block but I not sure how to produce the constant  
> pool
> with the jumptable like in the description below.
>
>>
>> There have been lots of bugs in ARMConstantIslands where it's off  
>> by 1, but I haven't seen one where it's off by a lot like this.
> The big offset is due to this one large basic block and is not a  
> problem with alignment or any off by 1  issue.
>>
>> On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote:
>>
>>> Hello,
>>>
>>> This problem happens in ToT under specific conditions - namely  
>>> there is
>>> a big BB#671 basic block of code
>>> the just copies data from memory location to another. At the  
>>> beginning
>>> of BBB#671 r0 is loaded
>>> from the jumptable in the constant pool immediately after it.
>>> Displacement from the pc
>>> in this case is #1476 which is way above magic #1020 hence the
error
>>> after fixup.
>>> Both ARMCodeEmitter::emitLEApcrelJTInstruction() and  
>>> emitJumpTableAddress()
>>> are responsible for the offending instruction adr    r0,  
>>> #.LJTI8485_1_1
>>> But besides the fact that they do not complain about the invalid  
>>> offset
>>> from the pc I do not see
>>> anything wrong here.
>>>
>>> The problem seems to be in the ARMConstantIslands which is not  
>>> splitting
>>> BB#671 into
>>> smaller pieces and thus producing over the limit 'add'
opcode.
>>>
>>> This code fragment below is produced from a rather large bitcode  
>>> file
>>> that resists being reduced to something
>>> more manageable. As a result keystrokes in gdb are very
"expensive
>>> " and
>>> taxing my  machine rather heavily.
>>>
>>> Any thoughts and hints on debugging this issue would be much  
>>> appreciated!
>>>
>>> I have used  llc with these options to produce the output:
>>>
>>> llc -O0 -regalloc=fast  -relocation-model=pic  l.bc -o ll-2.8.s
>>>
>>>    bhi    .LBB8485_455
>>> @ BB#671:                               @ %bb154
>>>                                        @   in Loop:  
>>> Header=BB8485_1112
>>> Depth=5
>>>    adr    r0, #.LJTI8485_1_1
>>>    ldr    r1, [sp, #3300]
>>>    ldr    r2, [r0, r1, lsl #2]
>>>    ...
>>>    lots of boring code omitted
>>>    ...
>>>    add    pc, r2, r0
>>> .LJTI8485_1_1:
>>>    .set    .L8485_1_1_set_70,.LBB8485_70-.LJTI8485_1_1
>>>    .long     .L8485_1_1_set_70
>>>    .set    .L8485_1_1_set_49,.LBB8485_49-.LJTI8485_1_1
>>>    .long     .L8485_1_1_set_49
>>>    .set    .L8485_1_1_set_419,.LBB8485_419-.LJTI8485_1_1
>>>    .long     .L8485_1_1_set_419
>>>    .set    .L8485_1_1_set_1085,.LBB8485_1085-.LJTI8485_1_1
>>>    .long     .L8485_1_1_set_1085
>>>    .set    .L8485_1_1_set_439,.LBB8485_439-.LJTI8485_1_1
>>>
>>> When assembler runs on the output we get:
>>>
>>> ll-2.8.s:1916640: Error: invalid constant (5c4) after fixup
>>>
>>> Standard disclaimer:
>>> All of the tools used were proper ARM cross compiler,assembler, etc
>>> running on x86_64
>>> and no bitcode was ever harmed during debugging.
>>>
>>> Cheers,
>>> Pawel
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>

On 8/18/2010 1:47 PM, Dale Johannesen wrote:
>
> On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote:
>
>> On 8/18/2010 12:39 PM, Dale Johannesen wrote:
>>> I can look at this, but you'll need to send the .bc file. 
Please
>>> open a PR?
>>
>> I would do it but I am in  a bit of a pickle as the .bc is from 
>> propriety code and
>> I can  not post it.
>
> Can't help much then.  You might look into obfuscating the code, some 
> companies are OK with distributing obfuscated IR.
> -debug-only=arm-cp-islands will show you what ARMConstantIslands is 
> thinking pretty well.
Oh -debug-only=arm-cp-islands works very very well! It just that now 
after running it I have
a 1.5GB log file problem in addition to the original
issue.
>
>> Anyway, I have been trying to re-create the problem in a simpler test 
>> case.
>> Since, I do not have access to the source for the .bc I am trying to 
>> guess
>> the kind of code that created the problem. So far I was able to 
>> replicate
>> the one large basic block but I not sure how to produce the constant 
>> pool
>> with the jumptable like in the description below.
>>
>>>
>>> There have been lots of bugs in ARMConstantIslands where it's
off by
>>> 1, but I haven't seen one where it's off by a lot like
this.
>> The big offset is due to this one large basic block and is not a 
>> problem with alignment or any off by 1  issue.
>>>
>>> On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote:
>>>
>>>> Hello,
>>>>
>>>> This problem happens in ToT under specific conditions - namely 
>>>> there is
>>>> a big BB#671 basic block of code
>>>> the just copies data from memory location to another. At the
beginning
>>>> of BBB#671 r0 is loaded
>>>> from the jumptable in the constant pool immediately after it.
>>>> Displacement from the pc
>>>> in this case is #1476 which is way above magic #1020 hence the
error
>>>> after fixup.
>>>> Both ARMCodeEmitter::emitLEApcrelJTInstruction() and 
>>>> emitJumpTableAddress()
>>>> are responsible for the offending instruction adr    r0, 
>>>> #.LJTI8485_1_1
>>>> But besides the fact that they do not complain about the
invalid
>>>> offset
>>>> from the pc I do not see
>>>> anything wrong here.
>>>>
>>>> The problem seems to be in the ARMConstantIslands which is not 
>>>> splitting
>>>> BB#671 into
>>>> smaller pieces and thus producing over the limit 'add'
opcode.
>>>>
>>>> This code fragment below is produced from a rather large
bitcode file
>>>> that resists being reduced to something
>>>> more manageable. As a result keystrokes in gdb are very
"expensive
>>>> " and
>>>> taxing my  machine rather heavily.
>>>>
>>>> Any thoughts and hints on debugging this issue would be much 
>>>> appreciated!
>>>>
>>>> I have used  llc with these options to produce the output:
>>>>
>>>> llc -O0 -regalloc=fast  -relocation-model=pic  l.bc -o ll-2.8.s
>>>>
>>>>    bhi    .LBB8485_455
>>>> @ BB#671:                               @ %bb154
>>>>                                        @   in Loop:
Header=BB8485_1112
>>>> Depth=5
>>>>    adr    r0, #.LJTI8485_1_1
>>>>    ldr    r1, [sp, #3300]
>>>>    ldr    r2, [r0, r1, lsl #2]
>>>>    ...
>>>>    lots of boring code omitted
>>>>    ...
>>>>    add    pc, r2, r0
>>>> .LJTI8485_1_1:
>>>>    .set    .L8485_1_1_set_70,.LBB8485_70-.LJTI8485_1_1
>>>>    .long     .L8485_1_1_set_70
>>>>    .set    .L8485_1_1_set_49,.LBB8485_49-.LJTI8485_1_1
>>>>    .long     .L8485_1_1_set_49
>>>>    .set    .L8485_1_1_set_419,.LBB8485_419-.LJTI8485_1_1
>>>>    .long     .L8485_1_1_set_419
>>>>    .set    .L8485_1_1_set_1085,.LBB8485_1085-.LJTI8485_1_1
>>>>    .long     .L8485_1_1_set_1085
>>>>    .set    .L8485_1_1_set_439,.LBB8485_439-.LJTI8485_1_1
>>>>
>>>> When assembler runs on the output we get:
>>>>
>>>> ll-2.8.s:1916640: Error: invalid constant (5c4) after fixup
>>>>
>>>> Standard disclaimer:
>>>> All of the tools used were proper ARM cross compiler,assembler,
etc
>>>> running on x86_64
>>>> and no bitcode was ever harmed during debugging.
>>>>
>>>> Cheers,
>>>> Pawel
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>
>
>
>