llvm dev - Aug 2019 - Thumb frame pointer register

Hello all,

I noticed that for ARM Thumb target, llc uses r7 as frame pointer (gcc does
not do this AFAIK), and this register should therefore not be used as a
general-purpose register.

However, when compiling mbedTLS, which contains some code that is highly
optimized for ARM platform and uses r7 to efficiently perform an operation.
This raises an exception since r7 is now the frame pointer.

I tried passing -fomit-frame-pointer but this is just a hacky workaround
and does not work in this case, since the function here does indeed need
frame pointer.
```
The -fomit-frame-pointer option instructs the compiler to not store stack
frame pointers if the function does not need it. You can use this option to
reduce the code image size.
```

My question is, how can I instruct the register allocator to use another
register as frame pointer, or at least turn off the use of frame pointer? I
tried changing the ABI with -mabi and -meabi but nothing works so far.

Thanks a lot for your help,

Cheers,

Son Tuan Vu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190821/489f72d3/attachment.html>

Hi Son Tuan,

On Wed, 21 Aug 2019 at 06:05, Son Tuan VU via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I noticed that for ARM Thumb target, llc uses r7 as frame pointer (gcc does
not do this AFAIK), and this register should therefore not be used as a
general-purpose register.
This is generally considered an ABI matter. On EABI and GNUEABI
platforms, I believe both GCC and Clang use r7 in Thumb mode, but r11
in ARM mode. This isn't configurable.

So I'd suggest making sure llc is producing ARM code for that
particular file: for example by using -mtriple=armv7-linux-gnueabihf
rather than -mtriple=thumbv7-linux-gnueabihf.

Cheers.

Tim.

On Wed, 21 Aug 2019 at 06:05, Son Tuan VU via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello all,
>
> I noticed that for ARM Thumb target, llc uses r7 as frame pointer (gcc does
not do this AFAIK), and this register should therefore not be used as a
general-purpose register.
>
> However, when compiling mbedTLS, which contains some code that is highly
optimized for ARM platform and uses r7 to efficiently perform an operation. This
raises an exception since r7 is now the frame pointer.
>
> I tried passing -fomit-frame-pointer but this is just a hacky workaround
and does not work in this case, since the function here does indeed need frame
pointer.
> ```
> The -fomit-frame-pointer option instructs the compiler to not store stack
frame pointers if the function does not need it. You can use this option to
reduce the code image size.
> ```
Can you let us know which function in mbedTLS you are referring to. I
found
https://tls.mbed.org/kb/development/arm-thumb-error-r7-cannot-be-used-in-asm-here
on the mbedTLS website which implies that you should use
-fomit-frame-pointer. I would be very surprised for code in mbedTLS to
simultaneously require a frame pointer and reserve r7 in Thumb state.
There may be some confusion about what GCC does as arm-none-eabi-gcc
uses -fomit-frame-pointer by default. As Tim points out, I think
you'll find that gcc will use r7 as the frame pointer if
-fno-omit-frame-pointer is used.

Peter
>
> My question is, how can I instruct the register allocator to use another
register as frame pointer, or at least turn off the use of frame pointer? I
tried changing the ABI with -mabi and -meabi but nothing works so far.
>
> Thanks a lot for your help,
>
> Cheers,
>
> Son Tuan Vu
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks Tim & Peter,

I am referring to mpi_montmul function from library/bignum.c, and this
problem only occurs at clang -O3, so for the moment I am compiling the
library with clang -02.

As for GCC, if -fno-omit-frame-pointer is NOT used, it doesn't use r7 as
frame register, while clang uses r7 by default (even without
-fno-omit-frame-pointer).

So my question is how to turn the use of frame pointer off for clang/llc?

Son Tuan Vu


On Wed, Aug 21, 2019 at 11:18 AM Peter Smith <peter.smith at linaro.org>
wrote:
> On Wed, 21 Aug 2019 at 06:05, Son Tuan VU via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hello all,
> >
> > I noticed that for ARM Thumb target, llc uses r7 as frame pointer (gcc
> does not do this AFAIK), and this register should therefore not be used as
> a general-purpose register.
> >
> > However, when compiling mbedTLS, which contains some code that is
highly
> optimized for ARM platform and uses r7 to efficiently perform an operation.
> This raises an exception since r7 is now the frame pointer.
> >
> > I tried passing -fomit-frame-pointer but this is just a hacky
workaround
> and does not work in this case, since the function here does indeed need
> frame pointer.
> > ```
> > The -fomit-frame-pointer option instructs the compiler to not store
> stack frame pointers if the function does not need it. You can use this
> option to reduce the code image size.
> > ```
>
> Can you let us know which function in mbedTLS you are referring to. I
> found
>
https://tls.mbed.org/kb/development/arm-thumb-error-r7-cannot-be-used-in-asm-here
> on the mbedTLS website which implies that you should use
> -fomit-frame-pointer. I would be very surprised for code in mbedTLS to
> simultaneously require a frame pointer and reserve r7 in Thumb state.
> There may be some confusion about what GCC does as arm-none-eabi-gcc
> uses -fomit-frame-pointer by default. As Tim points out, I think
> you'll find that gcc will use r7 as the frame pointer if
> -fno-omit-frame-pointer is used.
>
> Peter
>
> >
> > My question is, how can I instruct the register allocator to use
another
> register as frame pointer, or at least turn off the use of frame pointer? I
> tried changing the ABI with -mabi and -meabi but nothing works so far.
> >
> > Thanks a lot for your help,
> >
> > Cheers,
> >
> > Son Tuan Vu
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190821/a99ce81a/attachment.html>