This patch is a reincarnation of D21467 and 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.
I think for the moment, AndroidABI32, ABI*, and GNUABI32 are superfluous. We can infer enough and/or rely on clang to disambiguate the precise target.