[cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal

[Eric Christopher]

I knew I'd regret leaving that option in for the MIPS port back in 99.
Basically this is the only acceptable way for mcpu to exist, but should
never have been added to the GCC aarch64 port at all since there's no
compatibility with existing build systems to worry about.

I would still like you to show this mythical piece of software that needs
this compatibility.

-eric
On Jan 8, 2014 3:06 AM, "Bernie Ogden" <bogden at arm.com> wrote:

> I think there's an error in the example here.
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/AArch64-Options.html still
> documents -mcpu, and that march does not take CPUs as arguments. A local
> GCC developer tells me that the documentation is wrong in that -mcpu is
> actually a shorthand for specifying both -mtune and -march, but that the
> option is certainly there.
>
>
>
> If we want GCC comptability then that's what we have to do, unless someone
> knows that GCC ARM/AArch64 is actually going to move away from this.
>
>
>
> Do we want GCC compatibility?
>
>
>
> Regards,
>
>
>
> Bernie
>
>
>
>
>
> *From:* cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] *On
> Behalf Of *Eric Christopher
> *Sent:* 07 January 2014 21:37
> *To:* Renato Golin; Amara Emerson; Clang Dev; LLVM Dev
> *Subject:* Re: [cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal
>
>
>
> Parsing the arch string is a bit icky, but I don't really have too much of
> a problem with it - and it's better than -mcpu so...
>
>
>
> -eric
>
>
>
> On Tue Jan 07 2014 at 9:23:43 AM, Renato Golin <renato.golin at linaro.org>
> wrote:
>
> On 7 January 2014 17:05, Amara Emerson <amara.emerson at arm.com> wrote:
>
> We plan on implementing this interface for AArch64 Clang in future, and
> completely dropping the current support for -mfpu. This means that -march
> will become the preferred way to specify the target CPU/architecture.
>
>
>
> Hi Amara,
>
>
>
> This is something we were converging on the ARM32 world, too, and I
> believe other targets would probably do the same, if not before us.
> Hopefully, that'd also help clean up the driver's code in the process.
>
>
>
> cheers,
>
> --renato
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140108/438392df/attachment.html>