Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. D20830 threaded an MCSubtargetInfo reference through MCAsmBackend::relaxInstruction, but this isn't the only function that would benefit from access. This patch removes the Triple and CPUString arguments from createMCAsmBackend and replaces them with MCSubtargetInfo.
This patch just changes the interface without making any intentional functional changes. Once in, several cleanups are possible:
* Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend
* Support 16-bit instructions when valid in MipsAsmBackend::writeNopData
* Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl
* Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221)
I'm not sure who to tag as reviewer, but given this enables useful ARM and X86 cleanups I'm tagging code owners for those targets. Also Lang Hames and Daniel Sanders for touching TargetRegistry recently. Feel free to add yourself as a reviewer to tag anyone else you think would be appropriate.
X86 maintainers: This currently causes some test failures related to the X86 HasNopl code which looks to me like I'm just exposing an existing bug. HasNopl is false if the CPU string is "generic", "i386", and a bunch of others. However, the CPU string is empty when passing llvm-mc arguments like `-arch=x86 -triple=i686-pc-linux-gnu`. but true for the empty string. This means `-triple=i686-pc-linux-gnu` allows long nops but `-triple=i686-pc-linux-gnu -mcpu=generic` doesn't, This patch means it will be "generic",which seems wrong. as selected by createX86MCSubtargetInfo and so HasNopl is false. CC @rafael, who last touched that HasNopl code.I've filed https://bugs.llvm.org/show_bug.cgi?id=35686