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

[Eric Christopher]

I apologize for the delay in replying here.

On Tue Nov 19 2013 at 1:00:33 AM, Bernard Ogden <Bernard.Ogden at arm.com>
wrote:

> I find the compatibility arguments more compelling than you do :)
>
>
To be clear you want compatibility with ARM32 here, not necessarily with
gcc (since you "ARM" added the gcc code and there's no existing toolchains
that target hardware outside of llvm).

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.
>
>
I don't think this is a valid argument here as I explained above.


> * 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.
>
>
I can agree with this.


> 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.
>
>
In general, I think that the existing ARM behavior in gcc is a mistake. I
complained about it a decade ago :)

Let's see if an example helps:


>
> 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?
>
>
I'm going to summarize a bit here on what most targets do in case it helps:

-march handles the particular cpu features you'd like to target. There are
then additional -m<foo> options that handle the specific cpu features that
can then be enabled/disabled via this. As an example from x86:

-march=core-i7 -mno-sse

Will target a core-i7 processor, but leave out the sse instructions. You
can see the parallel with -march=cortex-a7 -mfpumath=neon (or however it's
spelled).

The default tuning for this will be for a core-i7. But let's say you don't
want to do that, you actually want your code to be tuned for a haswell and
not a generic i7 (though it needs to run across multiple architectures so
you set the minimum hardware requirements via -march) you'd then do
something like:

-mtune=haswell

and you'd have something scheduled/instruction selected for a haswell, but
only using the hardware features specified by the -march and -m options
above.

Make sense?

Basically, in general, there's no existing set of makefile/build targets
for aarch64 in the wild - there aren't any -march/-mcpu/-mtune sets going
on, it's a new architecture and now's a good time to set the specific
command line that should be supported. :)

-eric


> 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
> > >
> > >
> > >
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131216/bc3f88fa/attachment.html>