AArch64 Clang CLI interface proposal

Hi,

Clang for AArch64 currently accepts an -mfpu option to specify the FPU/NEON
unit. This behaviour, while consistent with the ARM target and ARM gcc, will
no longer be supported in AArch64 gcc. The preferred CLI for specifying
FPU/NEON units will be the use of the -march option with feature modifiers
(+[no]feature). The feature modifiers according to the GCC manual are:
* crypto
* fp
* simd (implies fp)

For example, "clang -march=cortex-a57+crypto" or "clang
-march=generic+nosimd". Whether or not simd (neon) is enabled by default is
an orthogonal issue.

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.

-mgeneral-regs-only:
This is an option currently supported by AArch64 GCC, which we would also
like to implement. Passing this option to the compiler should ensure that it
generates code which only uses the general purpose registers. Otherwise, the
compiler should throw an error.

Is this proposal reasonable?

Thanks,
Amara

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

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

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

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

I’m just stating that if GCC compatibility is desired then we have to have -mcpu.

I don’t think there’s software that needs the compatibility, but it is easier for GCC projects to switch to clang if that compatibility is there - which I think is why we go for GCC compatibility in the first place?

(I raised http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 on the GCC docs.)

I’m just stating that if GCC compatibility is desired then we have to have -mcpu.

I don’t think there’s software that needs the compatibility, but it is easier for GCC projects to switch to clang if that compatibility is there - which I think is why we go for GCC compatibility in the first place?

(I raised http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 on the GCC docs.)

We typically add options in clang only if there is a user for them.

Shrug, my concern was the ridiculous arm32 version. If you want a confusing duplicate option for setting both when just march should do then knock yourself out.

Ah and thanks for the GCC bug. That should help clarify matters.

I assume that big. LITTLE support is coming as well in the option parser?

Hi Bernie,

GCC compatibility is always considered to be an important feature of LLVM,
not the *most* important one. We'll never go beyond reason to add GCC
compatibility just because, especially one that is poorly or not at all
documented.

The general rule of thumb is to ask the questions:
* Do we really need it?
* Isn't there any other way?
* Is this sane? Or should the original authors re-write their programs?

There has been some progress on both GCC and LLVM to co-operate, rather
than follow each other blindly, and I can see this as the only future for
both toolchains.

In this specific case, I'd strongly oppose to follow whatever GCC does,
since the Clang driver is already mind bogging. The only reasonable course
of action from here is to open the discussion in the GCC and LLVM community
together (not sure how, but we'll *have* to figure it out), and follow from
there.

cheers,
--renato

Upon thinking about this more, we could go with my original proposal about
-march accepting both architectures and cores, which would be a superset of
the values that gcc accepts for -march.

Once we have that, we can simply alias -mcpu to -march, perhaps taking
precedence over -march in the case where they're both specified. This should
give enough compatibility with gcc while also using the -march scheme that
Eric wanted.

On a related note, clang doesn't seem to do anything with -mtune for any
target, not even x86. Do we still want to keep it around? We never make the
distinction in the backend between a core that we do isel for and a core
that we optimize for.

Amara

I'm not against such a change, as long as it doesn't make the driver even
worse.

cheers,
--renato

Eric Christopher <echristo@gmail.com> writes:

I knew I'd regret leaving that option in for the MIPS port back in 99.

It didn't last long :slight_smile: -mcpu for MIPS went away in 2002.

Thanks,
Richard

Yes, it would be useful to have a clear statement of what the GCC behaviour actually is.

big.LITTLE isn’t on my to do list right now.

I think that this works (and adds no appreciable driver complexity) provided
that we're not expecting to support -mtune. If clang is (one day) going to
be able to isel based on one target and optimize based on another then we
might find ourselves wanting to change the meaning of -march from 'isel and
optimize' to 'isel only'. So Amara's question about -mtune (or more
generally, do we want to be able to separate isel and optimization) seems
quite relevant.

This also only gives one-way compatibility, which seems good enough for
selfish clang purposes. As Renato pointed out, that may be the wrong
attitude. Should we try to engage the GCC community here?

Hi Renato,

Thanks, that’s a helpful explanation of the position. I sympathise with your ‘co-operation over following’ view, though I’m also not sure how.

I’m not convinced that having both -mcpu and -march makes the driver any more mind boggling - I’m sure we could implement something tidier than what happened for the ARM32 side. But I think Amara’s superset proposal would have a simpler implementation, so let’s move on with that for now.

Regards,

Bernie

Hi Bernie,

I'm doing this internally at Linaro and some ARM GCC folks first, just to
see how receptive they are about a formal cooperation. I'm expecting
resistance and dismissal, but I'm hoping to be wrong. :wink:

Would be good if every one could ask their GCC friends to come and play
with us, so that ends up as a unison request, not just dust in the wind.

cheers,
--renato

Ping. Can I assume that we’re ok with this interface proposal then?

Amara

Hi Amara,

Sorry, I got no replies from the GCC folks. I think we all agree that this
is a good way forward, so let's just go with it and try to keep
compatibility as an equally important, but secondary goal.

cheers,
--renato