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

[Rafael Espíndola via llvm-dev]

> All callers of createMCAsmInfo() and LLVMCreateDisasmCPUFeatures() would need to specify the ABI. In the case of LLVMCreateDisasmCPUFeatures(), they'd move to a new variant of this function and some backward compatibility fixups would be left in the pre-existing version to maintain its current level of functionality where only the default ABI for the triple is available. IRObjectFile would need some means of determining the ABI otherwise IRObjectFile::CollectAsmUndefinedRefs() would produce a slightly different result for some assembly inputs. This is because a small number of directives introduce references on particular ABI's and not on others. I think this information would be best delivered via the LLVM-IR but adding the ABI in LLVM-IR files has been strongly opposed in previous discussions. Also, IRObjectFile may need the CPU due to some changes to relocation rules for MIPS32R6 that prevent elimination of relocations that can be evaluated locally which would lead to the same issue.

Yes, that seems worse than just adding a few extra triples.

> I should also mention that Debian's binutils package already contains downstream patches to define 'gnuabi64' and select the appropriate default behaviour. I assume this will be upstreamed in the near future.

Thanks, that is another strong indication for going with the triples.

>> Also, do you plan to deprecate the other ways of passing mips abi info
>> and use only a normalized triple? If so I am OK with adding these
>> extra triples.
>
> Yes, http://reviews.llvm.org/D21069 makes it mandatory to pass the ABI in the triple.

Awesome.

Thanks,
Rafael