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

[Sjoerd Meijer via llvm-dev]

Hi Tim and Peter,


Thanks for your comments! Yes, I now see now  that with GCC, the ARM/Thumb state does not depends on optimisation levels, but it is a toolchain default (I've learned something today! :-)).


But I guess it doesn't change much about my observations:

- we have an inconsistency/discrepancy between GCC's and Clang/LLVM's behaviour,

- and most likely Clang's default behaviour, for a native toolchain users which I am now, gives surprising and perhaps undesired results. I.e., the equivalent of GCC's "gcc -Os", which is "clang -Oz", doesn't really do what I want/expect. And being a native toolchain user is quite important here, because that means I don't expect it would be necessary to provide --target and then provide some triple to get me Thumb when I've already specified -Oz (but perhaps I am totally wrong here).


I agree now that changing Thumb/ARM state depending on optimisation levels might be confusing and not worth the effort, but that leaves me wondering what our options are (not a rhetorical question). I guess that is:

1) keep it as it is (I haven't looked at the docs yet, but perhaps document this better if necessary), or

2) adopt GCC's behaviour and flip the default?


Cheers,

Sjoerd.

________________________________
From: Tim Northover <t.p.northover at gmail.com>
Sent: 15 November 2018 16:48:38
To: Peter Smith
Cc: Sjoerd Meijer; LLVM Developers Mailing List; nd
Subject: Re: [llvm-dev] [cfe-dev] [RFC][ARM] -Oz implies -mthumb

On Thu, 15 Nov 2018 at 14:27, Peter Smith via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> My vote is not imply ARM/Thumb state changes with optimization
> options. We've already got two ways to do it --target=thumb-none-eabi,
> --target=arm-none-eabi and -mthumb/-marm I think the potential
> confusion outweighs the potential benefit. I'm just one voice though.

I agree with that.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181115/0395070a/attachment.html>