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

[Bernie Ogden]

I find the compatibility arguments more compelling than you do :)

More specifically - 

* GCC compatibility is a goal of the clang driver. Targeting is inherently
different so perhaps we shouldn't worry too much about that in this case. I
don't see the pain that justifies making the break in this case, but I'm
willing to believe it is there.

* AArch32 compatibility is important to me. I really don't want users to
have to learn subtly different CLIs to compile code to run on any two ARM
cores, let alone to run in different execution states on a single core.

Let's set aside GCC compatibility for now. We could get to the behaviour you
want without breaking AArch32 compatibility by deprecating -mcpu for the ARM
backend and updating -march to take the CPUs as well (and adding -mtune?).
We would then have:

AArch64: Target selection via -march and -mtune only
AArch32/ARM: Target selection via -march, expanded to take CPU names as
well, and -mtune. -mcpu remains but is deprecated.

The AArch64 backend is therefore not GCC compatible, but you argue this
doesn't matter. The AArch32 backend becomes compatible with both GCC and
AArch64. We lose GCC compatibility if we discard -mcpu one day, but perhaps
GCC itself will change.

I could live with this - I've not been here long enough to have a sense of
what the wider community will think.


As for the rest, I'm getting lost in terminology. cpu and arch seem to mean
slightly different things depending on toolchain and I'm not all that
steeped in GNU ways. But I think you're proposing that the triple should
identify a backend/architecture 'family', and identification of either a
specific architecture version or a cpu should be set by -march. This sounds
reasonable enough to me - though I think the main value is in having a
single set of rules for how target selection works, almost regardless of
what the specifics are. So long as they're not too crazy.

While we're on this subject, what would you expect -march=armv7/armv8 to
mean? The current behaviour in the ARM backend is to set a default CPU to
represent the arch, so armv7a, for instance, means cortex-a8. Similarly, the
v8 backend assumes NEON and FP are present, which is likely but not
architecturally guaranteed. This kinda gives a 'pragmatically useful' set of
subtarget features, but certainly won't produce code guaranteed to run on
any valid implementation of the architecture. I don't necessarily have a
problem with this, I'd just like to know if you think this is fine, or if
this is something else you would like to see change?

Regards,

Bernie


> -----Original Message-----
> From: Eric Christopher [mailto:echristo at gmail.com]
> Sent: 19 November 2013 03:06
> To: Bernard Ogden
> Cc: Nigel Stephens; Tim Northover; Amara Emerson; cfe-
> commits at cs.uiuc.edu
> Subject: Re: r193740 - [AArch64] Add some CPU targets for "generic", A-
> 53 and A-57.
> 
> 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
> >
> >
> >