[cfe-dev] [LLVMdev] AArch64 Clang CLI interface proposal
bogden at arm.com
Thu Jan 9 01:29:07 PST 2014
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
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
> -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
> give enough compatibility with gcc while also using the -march scheme
> Eric wanted.
> On a related note, clang doesn't seem to do anything with -mtune for
> target, not even x86. Do we still want to keep it around? We never make
> distinction in the backend between a core that we do isel for and a
> that we optimize for.
More information about the cfe-dev