[llvm-dev] [cfe-dev] [RFC][ARM] -Oz implies -mthumb

[Peter Smith via llvm-dev]

My understanding is that whether a gcc toolchain defaults to ARM or
Thumb is a configuration time decision by whomever builds the
toolchain. The linaro arm-linux-gnueabihf toolchain I have defaults to
-mthumb and that doesn't vary for -mcpu or any other command line
option. I haven't got a gcc to hand that defaults to -marm so that I
can test whether -mcpu=cortex-m3 will change that to Thumb. If I try
-marm -mcpu=cortex-m3 I get "error: target CPU does not support ARM
mode".

Can you give us a more concrete example about where GCC is inconsistent?

For clang I'm not particularly fond of -Oz implying a change of
instruction set state. I think that it would be difficult to document
properly, especially how to tell clang that I really did mean -Oz on
ARM. As well as being a bit messy to implement.

I think that most users of clang would prefer to use Thumb(2) than
ARM, although how to make change globally and give people enough
warning could be challenging and we'd need to get a consensus from the
community. I'd also not want to be the person updating all the tests
with -marm.

The reset vectors on some old architectures did need to be ARM state,
although I think they had to be written in assembly. It is possible
though that someone is using clang as the assembler driver and we'd
pass through -mthumb when they weren't expecting it.

Peter
On Thu, 15 Nov 2018 at 12:39, Tim Northover via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> On Thu, 15 Nov 2018 at 12:25, Bruce Hoult <brucehoult at sifive.com> wrote:
> > OK, I just checked, and -mcpu=cortex-{m3,m4,m7,a7,a9,a15,a53} gives Thumb at -O1, -O1, -Os on the following gcc:
>
> If anything I'd be inclined to just default to Thumb always. I haven't
> checked myself, but rumour has it the icache benefits make it faster
> than ARM code as well as smaller in most cases. My one worry there is
> with reset vectors, which I believe must be implemented in ARM in some
> cases; but since GCC itself appears to be inconsistent here, hopefully
> those people are already explicit about their needs.
>
> Cheers.
>
> Tim.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev