[PATCH] D21467: [llc+llvm-mc] Prefer applying -mabi to the triple where possible and allow Mips to take ABI information in the triple.

Daniel Sanders via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 17 05:57:31 PDT 2016

dsanders created this revision.
dsanders added a subscriber: llvm-commits.
dsanders added dependencies: D21466: [mips] Don't derive the default ABI from the CPU in the backend., D21465: [llc+llvm-mc] Replace the hidden -target-abi option with a -mabi thats visible in --help..
Herald added subscribers: sdardis, dsanders, srhines, danalbert, tberghammer.

The primary aim of this patch (and the clang counterpart) is to make it possible
to enable IAS by default for the N64 ABI (which is almost ready for it) without
also enabling it for the N32 ABI (which is definitely not ready). The same
change also lays the necessary ground work for fixing the N32 support such as
picking the right ELFCLASS and relocation encoding (N32 doesn't support the
3-relocs-in-1 encoding that N64 has).

The overall approach is to move away from the MCTargetOptions::ABIName way of
specifying the ABI (which until fairly recently was only in use by MIPS) and
move to specifying the ABI in the triple like other targets. Clang and API
users will then be required to specify the correct triple for the ABI they wish
to target.

In more detail:
Added the following environment values to llvm::Triple to explicitly
specify the ABI as part of the environment component of the triple:
* ABI32, ABIN32, ABI64
* AndroidABI32, AndroidABI64

ABI32/AndroidABI32/GNUABI32 are used internally to distinguish between the case
where O32 has been specified, and the case where the default ABI is implied.
This matters for triples such as mips64-linux-gnu where the default ABI is
context sensitive and could be any of the three main ABI's depending on
the environment. It is unlikely that these 'ABI32' suffixes will be seen in
GNU Triples.

In this patch, the MIPS backend will accept ABI's through either
MCTargetOptions::ABIName or the triple. A subsequent patch will restrict
this so that the MIPS backend only accepts ABI information from the triple
to avoid the potential for confusion caused by mismatches between the
triple and MCTargetOptions. At that point a corresponding clang patch will
be required to ensure proper usage and C++ API users who pass non-empty ABI
names will need to add something like:
  Triple ABITriple = TT.getABIVariant(ABIName)
  if (ABITriple.getArch() != Triple::UnknownArch) {
    TT = ABITriple;
    ABIName = ""
to their code. C-API users will be unaffected by this requirement since they
are currently unable to specify the ABI.

The test changes are as follows:
  Changed gnueabi to gnu in the triple. EABI has been removed recently
  because it was untested and had bitrotted.
  Made the OS component of the triple known since getABIVariant() needs to
  know the OS to apply the ABI information to the triple.
  Switched daddiu's for addiu's since O32 prohibits the use of 64-bit GPRs.

See http://reviews.llvm.org/D20916 for an explanation as to why
MCTargetOptions::ABIName doesn't work for Mips.

Depends on D21466 and D21465



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D21467.61085.patch
Type: text/x-patch
Size: 22537 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160617/0e532147/attachment.bin>

More information about the llvm-commits mailing list