[PATCH] D38799: [mips] Add MIPS ABI enumeration and getter function to the Triple class

Simon Atanasyan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jan 7 10:26:29 PST 2018

atanasyan added a comment.

In https://reviews.llvm.org/D38799#904291, @rengolin wrote:

> In https://reviews.llvm.org/D38799#904251, @atanasyan wrote:
> > This patch is really MIPS specific. But I think the problem is actually more general. Now, for example, we have three "environment" GNU, EABI, and Musl and "HF" ABI variants for each of this environment. If we support more C libraries, we will have to add new `Environment` items for each supported environment+ABI pair. Something like NewLib, NewLibHF etc. The idea of this patch is to separate notions of Environment and ABI and escape growing the `Environment` enumeration if we need to add new ABI for existing "environment".
> I agree that we could clean up a lot of crud by separating environment from ABI, but this is not what this patch is doing, at least for every other non-Mips architecture. Adding more special treatments to the already special Triple class won't help.
> I also agree that ARM hasn't made that easy to begin with, and a lot of it is ARM's fault (the arch, not the company:).

>From my point of view, we have two options: a) exclude ABI information and pass it everywhere as a separate argument; b) keep ABI inside a triple, but separate environment and ABI entities. A disadvantage of the first option is that we have to change a lot of public API including the "C" interface. This patch tries to go alongside the second option. I agree that the patch changes MIPS parts only and does not touch ARM-specific ABIs. I'd be happy to provide more general solution and extend idea of the patch on other architectures if I get some sort of approval.



More information about the llvm-commits mailing list