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

Thu Dec 19 08:05:43 PST 2013

Thanks for the explanation. I'm own next response may be slow as I'm off for
Christmas after tomorrow, but let's carry on the discussion for a moment.

My main issue here is compatibility of AArch32 and AArch64 in clang. I think
we agree that that's achievable, even if it ends up being in one direction
only (i.e. AArch32 must be able to consume AArch64 CLI, but not necessarily
the other way around).

But there is still the issue of GCC compatibility.  Sure, LLVM is the only
compiler targeting real AArch64 hardware right now, but that will change and
AArch64 Linux is already available for virtual targets (e.g. through
Linaro). I don't think GCC is going to change to match clang and I think we
(the clang/LLVM community) want people to be able to use clang to compile
their 64-bit Linux applications.

AArch64 GCC does still use -march/-mcpu/-mtune. I understand that -march
specifies what is legal to do and is limited to taking 'architecture'
values, with modifications for optional features (e.g.
-march=armv8-a+nocrypto). -mtune specifies what to optimize for and takes
CPUs as arguments. -mcpu also takes CPUs as arguments and is a shorthand for
the other two options, so -mcpu=cortex-a53 is equivalent to -march=armv8-a
-mtune=cortex-a53. Whether or not this makes sense, it is what GCC does.

So, if we want to be compatible with GCC, we have to support these options.

From: Eric Christopher [mailto:echristo at gmail.com] 
Sent: 16 December 2013 23:36
To: Bernard Ogden; Nigel Stephens; t.p.northover at gmail.com; Amara Emerson;
cfe-commits at cs.uiuc.edu
Subject: RE: r193740 - [AArch64] Add some CPU targets for "generic", A-53
and A-57.

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/20131219/62d50cb9/attachment.html>