llvm dev - Dec 2013 - [LLVMdev] [PATCH] Select correct embedded libclang_rt on Darwin

>   When you decide to work on MachO/Darwin, I want to discuss the problems
with ELF vs. EABI (http://llvm.org/PR18187).
Well, I'm doing it now to some extent (working on disentangling the
ARM backend's various uses of isTargetIOS, isTargetDarwin, isMoonFull
as a starting-point).

The thing is, the main advantage of Triples is that they're largely
GCC-compatible. Without that perspective, it's a mess: ELF/COFF/MachO,
AAPCS/APCS, RTABI/GNUABI, Little/big-endian, even 32/64-bit on targets
with both are all largely orthogonal, but we're lumbered with picking
3-4 names and running with it.

There's an argument for moving to an extensible attribute-based system
instead, but it'd be a lot of work even if everyone agreed it was a
good idea.

Tim.

On 11 December 2013 14:52, Tim Northover <t.p.northover at gmail.com>
wrote:
> The thing is, the main advantage of Triples is that they're largely
> GCC-compatible.
The triple is a lie. ;)

You can't be compatible with a standard that doesn't exist. You can
only copy the same apparent behaviour, including the bugs. But you
know that...

> Without that perspective, it's a mess: ELF/COFF/MachO,
> AAPCS/APCS, RTABI/GNUABI, Little/big-endian, even 32/64-bit on targets
> with both are all largely orthogonal, but we're lumbered with picking
> 3-4 names and running with it.
I'm trying to solve the problem with the same constraints, not
re-invent the wheel. My main problem in that bug is that, in
ARMISelLowering, AAPCS is being used as a rough approximation for
EABI, which is totally wrong. And the flag I added isTargetEABI()
doesn't work because of the triple parsing. I can make divmod+mod
calls to __aeabi_*divmod library functions when isTargetAAPCS(), but
that would make GNU users unhappy.

My idea is to gather all information, not just first-come-first-serve
basis, and choose the parameters based on all of them. So,
arm-elf-eabi would be different than arm-elf-gnueabi, and both would
have ELF and EABI/GNUEABI flags set, as well as their respective
defaults.

Question are, in this weird cases:

 * Do we get the union, the intersection or last-overrides-first flags?
 * Are there enough tests to make sure we won't create unexpected
behaviour on non-weird cases?
 * Can we avoid confusion of unknown parameters, when anything is possible?

My idea was to create a flag on each triple block if it has been
parsed already by some level, or remove it from the list, and continue
until all parsers (env, os, arch, etc) have passed and not recognized.
Then, we can separate the enums for object type, ABI, PCS and set all
the flags on the Target objects, which will return the correct answer
to isTargetWhatever().

I'm not expecting compile time to increase, even if we pass several
times over the same strings, as triples normally are only a couple of
characters long anyway.

cheers,
--renato