[PATCH] D27662: [triple+llc+llvm-mc] Make triple and ABI name consistent

[Simon Atanasyan via Phabricator via llvm-commits]

atanasyan created this revision.
atanasyan added reviewers: rafael, echristo, sdardis.
atanasyan added a subscriber: llvm-commits.
atanasyan set the repository for this revision to rL LLVM.
Herald added subscribers: mehdi_amini, srhines, danalbert.
Herald added a reviewer: vkalintiris.

This patch is reincarnation of https://reviews.llvm.org/D21467 and https://reviews.llvm.org/D22304 initially created by Daniel Sanders.

The aim of this patch is to provide ABI selected by a user to all parts of LLVM backend. It is especially important for MIPS because for this target ABI name might significantly change environment and even architecture specified by a triple.

The primary changes is introduced by this patch are new ABI specific for MIPS target and new Triple:: getABIVariant method. This method accepts ABI name and makes the triple and the ABI consistent.

Using only MCTargetOptions::ABIName as a source of ABI selected by a user has some significant drawbacks for MIPS and is likely to lead to further problems down the line.

One of the drawbacks is that to enable IAS by default for N64 we need to make MCTargetOptions available to MipsMCAsmInfo which requires changing both the public C++ API and the public C API (LLVMCreateDisasmCPUFeatures() in particular). Furthermore, we would need to make similar changes to the public C++ API to make MCTargetOptions available to MipsMCCodeEmitter, MipsMCAsmBackend, and the MIPS implementation of createMCSubtargetInfo() to be able to fix IAS support for the N32 ABI. This then leads to tools like llvm-objdump needing to pass an ABI name into the create*() functions or knowing when the backend will ignore the values given. In my opinion, the plumbing needed for this approach is difficult and produces a poor outcome.

Beyond the API changes, there are some odd inconsistencies that look like they'll cause further problems in the future. For example, IRObjectFile not specifying the ABI in its CollectAsmUndefinedRefs function can cause the occasional unexpected undefined references for some inline assembly. Another example is that that IRLinker won't consider O32/N32/N64 modules to be link-incompatible with each other because it only compares the triples stored in the modules. It therefore won't realize that the O32 LLVM-IR has lowered the calling convention differently to the N64 LLVM-IR and link them anyway to produce a bad output. Making IRLinker aware of the ABI would require the ABI to be serialized in the LLVM-IR.


Repository:
  rL LLVM

https://reviews.llvm.org/D27662

Files:
  include/llvm/ADT/Triple.h
  lib/Support/Triple.cpp
  lib/Target/Mips/MCTargetDesc/MipsABIInfo.cpp
  test/CodeGen/Mips/compactbranches/no-beqzc-bnezc.ll
  test/MC/Mips/elf_reginfo.s
  test/MC/Mips/expansion-jal-sym-pic.s
  tools/llc/llc.cpp
  tools/llvm-mc/llvm-mc.cpp
  unittests/ADT/TripleTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D27662.81020.patch
Type: text/x-patch
Size: 21381 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161211/b492fdd3/attachment-0001.bin>