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

[Daniel Sanders via llvm-dev]

Thanks Renato and Rafael.

> On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> > Hi,
> >
> > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now
> trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not
> currently possible to enable IAS by default for the N64 ABI without also
> enabling it for the N32 ABI because this information is not reflected in the
> triple and that's the only information MipsMCAsmInfo has.
> 
> What would it take to pass more information to MipsMCAsmInfo?

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.

The other callers of createMCAsmInfo() either already have the ABI by one means or another, or would be able to figure it out if we extend ObjectFile to detect the ABI from the object*. Some of the tools that call createMCAsmInfo() link multiple object files (e.g. llvm-rtdyld, and llvm-dwp) and may therefore need to implement the ABI inter-linking rules.

Looking beyond enabling IAS for N64 towards fixing N32 support for IAS, the same requirements would apply to createMCSubtargetInfo(), createAsmPrinter() (because the Mips, PowerPC, AMDGPU, and WebAssembly targets call createMCSubtargetInfo() in their implementations), createMCCodeEmitter(), and createMCAsmBackend(). IRLinker would also need to handle the incompatibility between the O32 and N32/N64 ABI's IR-level since frontends can generate different IR for different calling conventions. Other targets handle this incompatibility by having different triples. I think N32 and N64 are compatible at the LLVM-IR level but I haven't proven this and it's moot since they aren't compatible with O32 which should also be allowed on MIPS64.

* This bit is slightly different from the description in http://reviews.llvm.org/D20916 where I believed many tools needed to provide the ABI but lacked the information to do so. Since writing that, I have added a facility to ObjectFile that allows llvm-objdump to detect the feature bits from the Object header. The same technique can be used for other tools that handle ObjectFiles.

> > For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and
> > Triple::GNUABI64. All three of these are supported by tools like binutils (by
> > virtue of a wildcard match '*linux-gnu*') and of these three,
> > Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by
> > Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used
> > by Debian for our N64 port. Once the ABI is in our backend triples, it can be
> > used by MipsMCAsmInfo to enable IAS by default for N64 without also
> > enabling it for N32. In later patches, such as D1292 this same information will
> > also be used to fix the N32 support for IAS.
> 
> I would be perfectly fine with this if instead of just hitting an
> wildcard these different triples actually meant different things to
> binutils.

That doesn't seem necessary since 'gnueabi' and 'gnueabihf' seem to be matched by a 'gnu*' wildcard too but I'm in favour of defining these triples in binutils if that's necessary to fix LLVM. I'd appreciate it if this patch series didn't have to wait until the triples are present in the binutils source though. Are you ok with us going ahead with this patch series while a corresponding binutils patch is being put together?

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.

> 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.

> Eric, what do you think?
> 
> Cheers,
> Rafael