[cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal

[Bernie Ogden]

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?

> -----Original Message-----
> From: Amara Emerson
> Sent: 08 January 2014 14:07
> To: 'Renato Golin'; Bernard Ogden
> Cc: Eric Christopher; LLVM Developers Mailing List; Clang Dev
> Subject: RE: [cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal
> 
> 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