llvm dev - Apr 2011 - [LLVMdev] big bitcode files producing bad ARM asm

I have a rather large bitcode file which when run through "llc -march arm
-O0" produces an asm file of about 500Mb. Trying to assemble this file with
the ios assembler on osx gives me lots of "branch out of range" errors
thanks to jump instructions overflowing the +/-32Mb relative jump limit.

I've tried running llc with the hidden "-arm-long-calls" option,
which solves the problem but forces everything to be an indirect branch. That
feels a bit like overkill, does anybody have a suggestion for what the right
solution might be?

Thanks,
Alex Mac

On Apr 25, 2011, at 6:01 PM, Alexander MacDonald wrote:
> I have a rather large bitcode file which when run through "llc -march
arm -O0" produces an asm file of about 500Mb. Trying to assemble this file
with the ios assembler on osx gives me lots of "branch out of range"
errors thanks to jump instructions overflowing the +/-32Mb relative jump limit.
> 
> I've tried running llc with the hidden "-arm-long-calls"
option, which solves the problem but forces everything to be an indirect branch.
That feels a bit like overkill, does anybody have a suggestion for what the
right solution might be?
I think that writing smaller functions or optimize it to be smaller are about
your only options. We have a constant island pass in the compiler that'll
let it figure out constant displacements, but the branch island bits is only in
the linker - and if you've got branches inside a single function of more
than 32MB you're just asking for trouble on the architecture.

-eric

On Apr 25, 2011, at 6:01 PM, Alexander MacDonald wrote:
> I have a rather large bitcode file which when run through "llc -march
arm -O0" produces an asm file of about 500Mb. Trying to assemble this file
with the ios assembler on osx gives me lots of "branch out of range"
errors thanks to jump instructions overflowing the +/-32Mb relative jump limit.
> 
> I've tried running llc with the hidden "-arm-long-calls"
option, which solves the problem but forces everything to be an indirect branch.
That feels a bit like overkill, does anybody have a suggestion for what the
right solution might be?
I don't think any other solutions are currently supported.

One problem is that the linker can move functions around as it pleases, so there
is no way of knowing which functions are going to be far away.

/jakob

On 25 Apr 2011, at 18:17, Eric Christopher wrote:
> On Apr 25, 2011, at 6:01 PM, Alexander MacDonald wrote:
> 
>> I have a rather large bitcode file which when run through "llc
-march arm -O0" produces an asm file of about 500Mb. Trying to assemble
this file with the ios assembler on osx gives me lots of "branch out of
range" errors thanks to jump instructions overflowing the +/-32Mb relative
jump limit.
>> 
>> I've tried running llc with the hidden "-arm-long-calls"
option, which solves the problem but forces everything to be an indirect branch.
That feels a bit like overkill, does anybody have a suggestion for what the
right solution might be?
> 
> I think that writing smaller functions or optimize it to be smaller are
about your only options. We have a constant island pass in the compiler
that'll let it figure out constant displacements, but the branch island bits
is only in the linker - and if you've got branches inside a single function
of more than 32MB you're just asking for trouble on the architecture.
> 
> -eric
I don't think it's branches within a single function that are a problem,
it's branches between functions that are far apart in the same object
file... I guess our only option is to split the bitcode file before codegenning,
is there any existing code that would help with that approach?

On 25 Apr 2011, at 18:20, Jakob Stoklund Olesen wrote:
> On Apr 25, 2011, at 6:01 PM, Alexander MacDonald wrote:
> 
>> I have a rather large bitcode file which when run through "llc
-march arm -O0" produces an asm file of about 500Mb. Trying to assemble
this file with the ios assembler on osx gives me lots of "branch out of
range" errors thanks to jump instructions overflowing the +/-32Mb relative
jump limit.
>> 
>> I've tried running llc with the hidden "-arm-long-calls"
option, which solves the problem but forces everything to be an indirect branch.
That feels a bit like overkill, does anybody have a suggestion for what the
right solution might be?
> 
> I don't think any other solutions are currently supported.
> 
> One problem is that the linker can move functions around as it pleases, so
there is no way of knowing which functions are going to be far away.
But the linker will fix branches that become "long-calls" after
it's shuffled things around right? so it would still be reasonable to try to
get LLVM to at least codegen a single object file correctly, assuming that the
codegen phase has some knowledge of roughly how big the branches will have to be
when it is generating the asm, which on second thought it probably doesn't
unless it knows the size of all functions before writing out the asm (I'm
not too familiar with the codegen phase).