r193740 - [AArch64] Add some CPU targets for "generic", A-53 and A-57.

[Eric Christopher]

On Tue, Nov 12, 2013 at 4:39 AM, Bernie Ogden <bogden at arm.com> wrote:
> I'm still not sure what the point at issue is.
>

Names are important. Not having confusing names is even more important.

> Based on a recent copy of the GCC manual and a little checking of CLI
> behaviour in recent Linaro releases, my understanding of the GCC behaviour
> for both AArch32 and AArch64 is:
>
> march: Takes an architecture such as armv8-a, with optional feature
> modifiers. Rejects CPU names. Determines which instructions can be selected.
>
> mcpu: A CPU such as cortex-a53, with optional feature modifiers. Rejects
> arch names. Determines which instructions can be selected.
>

This duplication is a serious pain. This is what I want to remove and
what I wanted to remove when I worked on gcc in the past.

> mtune: Like mcpu, but does not take feature modifiers and determines which
> optimizations should be applied rather than which instructions should be
> selected.
>
>
> So I think the suggestion is that -mcpu should be dropped. But this would be
> a GCC compatibility break, which I thought was considered undesirable?
> Having -march take CPU names would also be incompatible, but I think that
> that's a detail, not the main issue.
>

Given that the only shipping aarch64 hardware in the world shipped
with llvm I think the precedent should be there to match the shipping
llvm compiler. :)

As far as I know there aren't any shipping aarch64 compilers using gcc
targeting hardware and there's not a huge history here anyhow for
people to be confused.

> Have I understood all of this correctly? If not, I would be grateful if
> someone would set me straight.
>

Yes.

> I would like the two ARM flavours to behave consistently in clang/LLVM. I'm
> not sure right now what the AArch32 side does with mtune/march, but I
> suspect it's not quite what GCC does - I think clang probably ignores the
> former and implicitly selects a CPU for the latter. If we want to do
> something with -march/-mtune on one side, let's do it on the other too, and
> in the same way.

Sounds good to me here - in that I think gcc should change.

>
> I think not supporting -mcpu in AArch64 would add no value and would break
> compatibility with both GCC and with LLVM AArch32, so would be a Bad Thing.
> But perhaps I'm just ignorant - I'm happy to be educated.
>

I don't see much win in gcc compatibility here and there's no gain for
AArch32 - they're just different architectures, let's make a good
clean start.

As a thought I look at -mcpu like I would the cpu part of a gnu
triple, i.e. -mcpu will change the beginning of the triple:

-march=arm64

would get you a triple of arm64-apple-darwinNN

on darwin.

I think The Ideal Way(tm) is to use a -target flag with a full triple
and any particular architecture should go on as function attributes.
We're not there yet, but there's definitely work going that direction.
In general, this sort of thing is going to be a problem that we're
going to need to fix as universal cross compilation is becoming more,
not less important.

That said, for now, the cpu is part of the triple and the particular
architecture supported is passed via -target-cpu. There's no reason
for not compiling for -target aarch64-linux-gnu and -march=cortex-a53.
It's no different than compiling for a generic mips32r2 cpu and would
allow you to be as specific as you like. What compelling argument is
there for -mcpu existing?

-eric

>
>> -----Original Message-----
>> From: Nigel Stephens
>> Sent: 11 November 2013 20:49
>> To: Eric Christopher
>> Cc: Tim Northover; Bernard Ogden; Amara Emerson; cfe-
>> commits at cs.uiuc.edu
>> Subject: Re: r193740 - [AArch64] Add some CPU targets for "generic", A-
>> 53 and A-57.
>>
>>
>>
>> > On 11 Nov 2013, at 07:24 pm, "Eric Christopher" <echristo at gmail.com>
>> wrote:
>> >
>> > On Fri, Nov 8, 2013 at 9:02 AM, Tim Northover
>> <t.p.northover at gmail.com> wrote:
>> >>> To me it would be odd if the AArch64 CLI behaved differently to
>> AArch32,
>> >>> except where absolutely necessary.
>> >>
>> >> The general GCC interface has been encouraging -march/-mtune for
>> years
>> >> now. I've no idea what reasons 32-bit ARM chose to go against that,
>> >> but I'd want to make sure they were valid for AArch64 before
>> >> perpetuating it.
>> >>
>> >> Inertia doesn't seem like a great reason except for ARM-only
>> projects,
>> >> which are fairly rare.
>> >
>> > I agree with all of this.
>>
>> Likewise.
>>
>> The march/mtune mechanism seems to be the correct model, so long as
>> it's clear that march specifies the base architecture name (I.e. what
>> instructions/features are available to the compiler), and mtune a
>> specific CPU name (I.e. how do those instructions behave on a specific
>> microarchitecture). Confusion can reign if these get reversed!
>>
>> Nigel
>
>
>