[llvm-dev] Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32

[Eric Christopher via llvm-dev]

Hi Daniel,

While I'm sympathetic to the amount of work associated this appears to be
attempting to work around an API problem by changing triples needlessly.
There's already some ABI support in MCTargetOptions that I used when fixing
up the ARM port a while back and this use can either be extended or changed
depending on what's necessary. It may require plumbing, but that's expected
with an API being expanded for new uses. It appears that the command line
syntax is sufficient for the needs of enumerating target plus abi and if we
need to add more defaults then it shouldn't be too bad to do so.

Even if it weren't an API problem I'm not sure it'd be a good idea. I think
we could add a with-abi configuration option to match the current gcc one
rather than tacking it onto triple parsing.

That said, I'm more than happy to help you detangle the existing API and
come up with a good strategy for the MC level API.

Thanks!

-eric

ps. It also doesn't appear that Matthew (who took over my gcc
responsibilities, thanks!) has added support for this in gcc yet either.

echristo at dzur ~/b/build-gcc-mips64abin64> .../configure
--target=mips64-linux-gnuabi64 --enable-languages=c
echristo at dzur ~/tmp> ~/builds/build-gcc-mips64abin64/gcc/cc1 foo.c -o -
.file 1 "foo.c"
.section .mdebug.abiN32
...

On Fri, Jun 24, 2016 at 3:02 AM Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:

> Hi,
>
> Having recently enabled IAS by default for the MIPS O32 ABI, I'm now
> trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not
> currently possible to enable IAS by default for the N64 ABI without also
> enabling it for the N32 ABI because this information is not reflected in
> the triple and that's the only information MipsMCAsmInfo has. This would be
> fine if it N32 was also in a good state but the current N32 ABI support for
> IAS is badly broken and will likely take considerable effort to fix (and
> fixing it also requires solving the same key problem as enabling IAS for
> just N64). I therefore want to separate the two ABI's so that I can finish
> off N64 and then fix N32 afterwards.
>
> I've posted a series of patches that allow us to distinguish N32 and N64
> so that we can enable IAS for only N64  (D21465, D21467, D21069 for LLVM
> along with D21070, D21072 for clang). During the review of D21467, Rafael
> asked me to explain my approach here. I'm hoping that people will agree
> that this is an acceptable approach to take and that it's no different from
> how other targets handle certain ABI's and how we already handle
> -m32/-m64/-EL/-EB/etc.
>
> The approach I'm using is to encode the ABI information into the triple in
> the same way that ARM does for EABI and hardfloat, and the same way that
> X86 does for X32. These targets define variants of Triple::GNU for each of
> these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and
> Triple::GNUX32 values of the environment component of the triple and it's
> up to the frontend and/or API-user to pass the right thing to the backend.
>
> For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and
> Triple::GNUABI64. All three of these are supported by tools like binutils
> (by virtue of a wildcard match '*linux-gnu*') and of these three,
> Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by
> Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used by
> Debian for our N64 port. Once the ABI is in our backend triples, it can be
> used by MipsMCAsmInfo to enable IAS by default for N64 without also
> enabling it for N32. In later patches, such as D1292 this same information
> will also be used to fix the N32 support for IAS.
>
> At this point, you may be wondering what happens to Triple::GNU for
> triples like mips-linux-gnu and mips64-linux-gnu. The answer to this is
> that the API-user (e.g. clang) is expected to normalize such triples down
> to one of Triple::GNUABI32/GNUABIN32/GNUABI64. This can be as simple as
> adding:
>   Triple ABITriple = TT.getABIVariant(ABIName); // ABIName can be the
> empty string to get the default ABI.
>   if (ABITriple.getArch() != Triple::UnknownArch) {
>     TT = ABITriple;
>     ABIName = ""; // <- Only needed if this would end up in
> MCTargetOptions::ABIName.
>   }
> to the appropriate place in the caller. This is the same way clang handles
> the -m32, -m64, -EL, and -EB options with those options using
> get32BitArchVariant(), get64BitArchVariant(), getLittleEndianArchVariant(),
> and getBigEndianArchVariant() respectively to transform the triple for the
> backend.
>
> In summary, human end users of tools such as clang will continue using the
> same triples as they always have. These tools will then resolve them down
> to the effective triple (for example, in functions like clang's
> ComputeEffectiveClangTriple(), ComputeLLVMTriple(), and
> computeTargetTriple()). The MIPS backend will only see the triples that
> have a specific known ABI. I'd like to stress that this process is the same
> as the one we already use today for other options. For example
> 'x86_64-linux-gnu-clang -m32' transforms the triple with
> get32BitArchVariant() and passes 'i386-linux-gnu' to the backend.
>
> So far I've only been talking about Linux/GNU but the patch series also
> covers Linux/Musl, Linux/Android, and FreeBSD. I haven't talked about those
> because they are handled in the same way as the Linux/GNU case described
> above except that they use Triple::ABI32/ABIN32/ABI64 (or
> Android32/Android64 in the case of Android) instead of
> Triple::GNUABI32/GNUABIN32/GNUABI64.
>
> Why is the Triple approach better for MIPS than MCTargetOptions::ABIName?
> =========================================================================
>
> A major pragmatic reason is that it works today and the
> MCTargetOption::ABIName approach doesn't. It's also in keeping with other
> targets whereas until fairly recently MIPS was the sole user of
> MCTargetOptions::ABIName. There is currently a single PowerPC test and six
> ARM tests that use the -target-abi option that feeds
> MCTargetOptions::ABIName at the moment and both of these targets are only
> using it for relatively minor tweaks to the ABI.
>
> As things are today, MCTargetOptions::ABIName is good at fairly small
> tweaks to the ABI such as calling convention changes but it's unable to
> deal with more fundamental changes such as selecting between
> ELFCLASS32/ELFCLASS64 or enabling IAS. Some of these limitations look
> fixable if given months-years of effort but I can see potential problems
> once the obvious plumbing problem is fixed. Some of these problems such as
> preventing the linking of incompatible IR files in the IRLinker would
> require me to represent the ABI in the LLVM-IR (it's currently handled
> solely by the triple) which has been strongly opposed in earlier
> discussions about triples.
>
> I can provide more detail on some of the specific problems if required but
> this boils down to a choice between an easy paved road that other people
> use and that I know will end in a working state, or an unexplored path with
> known difficulties and an uncertain result.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160701/e4aece72/attachment.html>