[LLVMdev] [PATCH] Select correct embedded libclang_rt on Darwin

Renato Golin renato.golin at linaro.org
Wed Dec 11 07:07:34 PST 2013


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



More information about the llvm-dev mailing list