llvm dev - Mar 2014 - [LLVMdev] Contributing the Apple ARM64 compiler backend

Hi Hal,
> Is a different target triple the right thing to do here? I think that would
introduce a ton of user confusion. How about we keep the target triples as they
are, and add some other way to choose the desired backend?
In the short term, it's almost essential. Both of these targets are
going to be existing simultaneously for a while and all the LLVM tools
(for testing if nothing else) are setup to select the target based on
the triple.

Longer term we want a single backend (probably in the AArch64
directory since that's the official name). Theoretically, we could
drop "arm64" as a triple then (provided Clang still supported
"-arch
arm64" for compatibility), but in reality it would be a little odd if
"-arch arm64" worked but "--target arm64" didn't. I
suspect arm64 and
aarch64 will just become synonyms at that point.

Cheers.

Tim.

----- Original Message -----
> From: "Tim Northover" <t.p.northover at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Developers Mailing List" <LLVMdev at
cs.uiuc.edu>, "Renato Golin" <renato.golin at linaro.org>
> Sent: Friday, March 28, 2014 4:41:48 PM
> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
> 
> Hi Hal,
> 
> > Is a different target triple the right thing to do here? I think
> > that would introduce a ton of user confusion. How about we keep
> > the target triples as they are, and add some other way to choose
> > the desired backend?
> 
> In the short term, it's almost essential. Both of these targets are
> going to be existing simultaneously for a while and all the LLVM
> tools
> (for testing if nothing else) are setup to select the target based on
> the triple.
> 
> Longer term we want a single backend (probably in the AArch64
> directory since that's the official name). Theoretically, we could
> drop "arm64" as a triple then (provided Clang still supported
"-arch
> arm64" for compatibility), but in reality it would be a little odd if
> "-arch arm64" worked but "--target arm64" didn't. I
suspect arm64 and
> aarch64 will just become synonyms at that point.
Okay; this sounds reasonable, at least from an infrastructure perspective.
However, I think we'll want to have clear guidance regarding what we want
users, and more importantly, packagers, to do.

Are these two backends ABI compatible? If I have a toolchain setup for the
existing aarch64-linux-gnu triple, could I try the new backend and still have
clang find the linker and other object files in the lib/gcc directories? I
assume that, if that makes sense, we'll want to make that work.

 -Hal
> 
> Cheers.
> 
> Tim.
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

> Are these two backends ABI compatible?
They should be, where there's overlap. AArch64 doesn't have any MachO
support at the moment. ARM64 does have ELF support (obviously with
less testing than AArch64's). Any ABI discrepancy would be considered
a bug.
> If I have a toolchain setup for the existing aarch64-linux-gnu triple,
could
> I try the new backend and still have clang find the linker and other object
> files in the lib/gcc directories?
I believe so. You *should* be able to take any command-line you now
have with "--target aarch64-X-Y-Z", replace it with "--target
arm64-X-Y-Z" and it will just work.

Once the merge really gets started, that's a property everyone wants
to make sure is preserved: no regressions with existing commands for
trunk, and the final backend should be a drop-in replacement for both
iOS and ELF targets. Hopefully strictly better in both cases.

A big choice approaching is exactly how we go about the merge. In my
opinion trying an actual merge on .td files isn't going to work
(massive inconsistency even if we could make it happen technically) so
we're going to have to pick one of the two as a core for the final
backend, and strip all the useful bits out of the other one
cherry-pick style.

Cheers.

Tim.