[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
Renato Golin
renato.golin at linaro.org
Wed Jun 25 01:01:16 PDT 2014
On 25 June 2014 08:26, Tim Northover <t.p.northover at gmail.com> wrote:
> The main difference appears to be that GCC requires "armv8-a" in
> -march before any features, which I quite like. But even if I didn't
> it's close enough that we should follow anyway, for compatibility if
> nothing else.
Agreed.
> I think we should also specifically warn on the use of -mcpu:
> aggressively deprecate it on AArch64. AArch64 is a new architecture,
> there's no real excuse for using the legacy options.
Not entirely true. Legacy systems will be easily migrated to AArch64
by replacing previous flags with updated values (possibly migrated
from even older values still).
I'm fairly certain that GCC will enable any kind of legacy options,
which will encourage people to keep using it and complain that Clang
doesn't, and you know the rest of the story.
We could label them "lazy" but whoever had to deal with build systems'
crap knows how hard it is to make even the smallest of changes to a
legacy system already migrated twice. The guys that wrote the original
are all dead and your life is not long enough.
I'm not advocating to keep legacy, only that we think about it. Clang
already has the pretend-GCC-behaviour in many ways, and if that is
implemented orthogonally from the modern compiler (facade pattern for
those GOF-inclined), than we won't have to break our compiler but
still understand legacy for its merits.
One way to do this is to make triple/mcpu/mfpu parsing a way of
setting flags, and then feeding the flags back to -cc1, so that -cc1
doesn't have triples/mcpu/mfpu by definition.
>> I think those changes can easily build binary running on multiple CPUs and
>> get more compatible with gcc. Is this new proposal reasonable?
>
> I like it!
+1.
--renato
More information about the llvm-dev
mailing list