llvm dev - Jul 2015 - [LLVMdev] ARM Jump table pcrelative relaxation in clang / llc

Hi,

I have written a PassManager (IR) pass that seriously increases the size of
the original IR code.
As a result it seems that the generated machine code is incorrect (as of
LLVM 3.5): The AsmPrinter generates the following instruction :
adr r2, .LJTI4_0_0
when going through the MC streamer, I get a "fatal error: error in backend:
out of range pc-relative fixup" .
Apparently, the fixup does not hold in the 12 bits we have available. I
would have expected clang to perform relaxation on this instruction on that
particular case. Using the flag mrelax-all does not help.
Is there a way in the PassManager::runOnFunction to anticipate that so that
I can generate a IR code that would fit when converted to machine code?
Strangely enough, this is not happening when using llc to generate the code
from the bc file, I get the object file.
The target is armv5e-none-linux-androideabi ( I used -mtriple with llc).
I have seen a similar thread in 2012 " Questions on MachineFunctionPass and
relaxation of pcrel calls (ARM/thumb2)". Even though there have been
improvements since them, I am concerned with the difference of behavior of
the two tools.

Thanks for your help.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150705/1c72df3e/attachment.html>

Hi Eric,

On 5 July 2015 at 07:22, Eric Bentura <ebentura at gmail.com>
wrote:
> As a result it seems that the generated machine code is incorrect (as of
> LLVM 3.5): The AsmPrinter generates the following instruction :
> adr r2, .LJTI4_0_0
> when going through the MC streamer, I get a "fatal error: error in
backend:
> out of range pc-relative fixup" .
We've fairly recently fixed a bug that looks very similar (r238680,
which was well after 3.6)
> Apparently, the fixup does not hold in the 12 bits we have available. I
> would have expected clang to perform relaxation on this instruction on that
> particular case.
Agreed, whatever's going on it's a bug in the ARM backend.
> Is there a way in the PassManager::runOnFunction to anticipate that so that
> I can generate a IR code that would fit when converted to machine code?
Not as far as I'm aware; since the bug is further back there's no
reason to try and provide such information to earlier passes. The
backend is expected to cope with whatever you give it.
> Strangely enough, this is not happening when using llc to generate the code
> from the bc file, I get the object file.
That's weird. Even with "-filetype=obj" (the bug only occurs when
directly writing an object file)? Not that it really affects anything,
getting the same backend options with llc can be a bit tricky.
> Even though there have been
> improvements since them, I am concerned with the difference of behavior of
> the two tools.
The most common one I find perturbing output is "-mcpu" (even with a
triple), but really there are so many options front-ends can twiddle
that you just have to know what it's doing and copy that.

Cheers.

Tim.

Hi Tim,
Thank you for your answer.


*We've fairly recently fixed a bug that looks very similar (r238680,which
was well after 3.6)*

If I wanted to back port that to 3.5 where should I look at? Where in the
ARM backend the decision to relax an instruction is taken?




*That's weird. Even with "-filetype=obj" (the bug only occurs
whendirectly
writing an object file)? Not that it really affects anything,getting the
same backend options with llc can be a bit tricky.*

This is passing even with -filetype=obj. The transformation I apply are in
the optimizer so I must build the new bc to create the object file.

Thanks for your help

Eric

Le dimanche 5 juillet 2015, Tim Northover <t.p.northover at gmail.com> a
écrit :
> Hi Eric,
>
> On 5 July 2015 at 07:22, Eric Bentura <ebentura at gmail.com> wrote:
> > As a result it seems that the generated machine code is incorrect (as
of
> > LLVM 3.5): The AsmPrinter generates the following instruction :
> > adr r2, .LJTI4_0_0
> > when going through the MC streamer, I get a "fatal error: error
in
> backend:
> > out of range pc-relative fixup" .
>
> We've fairly recently fixed a bug that looks very similar (r238680,
> which was well after 3.6)
>
> > Apparently, the fixup does not hold in the 12 bits we have available.
I
> > would have expected clang to perform relaxation on this instruction on
> that
> > particular case.
>
> Agreed, whatever's going on it's a bug in the ARM backend.
>
> > Is there a way in the PassManager::runOnFunction to anticipate that so
> that
> > I can generate a IR code that would fit when converted to machine
code?
>
> Not as far as I'm aware; since the bug is further back there's no
> reason to try and provide such information to earlier passes. The
> backend is expected to cope with whatever you give it.
>
> > Strangely enough, this is not happening when using llc to generate the
> code
> > from the bc file, I get the object file.
>
> That's weird. Even with "-filetype=obj" (the bug only occurs
when
> directly writing an object file)? Not that it really affects anything,
> getting the same backend options with llc can be a bit tricky.
>
> > Even though there have been
> > improvements since them, I am concerned with the difference of
behavior
> of
> > the two tools.
>
> The most common one I find perturbing output is "-mcpu" (even
with a
> triple), but really there are so many options front-ends can twiddle
> that you just have to know what it's doing and copy that.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/0547fdc8/attachment.html>