When running under LTO, it is common to not specify the architecture
spec, which is used for setting up the target machine, and instead rely
on features specified in each function to generate the correct
instructions.
This works for the code generator, but the RISC-V backend uses the
AsmPrinter to do instruction compression, which does not see these
features but instead uses a MCSubtargetInfo object to see whether
compression is enabled. Since this is configured based on the
TargetMachine at startup, it will result in compressed instructions not
being emitted when it has not been given the 'c' TargetFeature, but the
function has it.
This changes the RISCVAsmPrinter to re-initialize the STI feature set
based on the current MachineFunction, such that compressed instructions
are now correctly emitted regardless of the method used to enable them.
Most backends seem to override AsmPrinter::runOnFunction entirely (the default implementation calls SetupMachineFunction), and avoid overriding SetupMachineFunction. Is there a particular reason you've chosen one vs the other? I note things like the ARM backend are pulling a SubtargetInfo out of the MachineFunction in their runOnFunction implementations, but I realise we end up needing a MCSubtargetInfo here - I presume that's the main reason?