On targets like Arm some relaxations may only be performed when certain architectural features are available. As functions can be compiled with differing levels of architectural support we must make a judgement on whether we can relax based on the MCSubtargetInfo for the function. This change passes through the MCSubtargetInfo for the function to fixupNeedsRelaxation so that the decision on whether to relax can be made per function. In this patch, only the ARM backend makes use of this information. We must also pass the MCSubtargetInfo to applyFixup because some fixups skip error checking on the assumption that relaxation has occurred, to prevent code-generation errors applyFixup must see the same MCSubtargetInfo as fixupNeedsRelaxation.
This addresses part of PR36542 where each function has the cpu and target features it was compiled with in its attributes, these features included support for Thumb2, whereas the default cpu passed to the lto plugin did not. As the decision on whether to relax was using the default cpu, a branch, used for a tail call by a Thumb2 function did not get relaxed to a wide branch.
I don't think that there is an alternative to making the relaxation decision based on per function information as if we use some kind of aggregate MCSubtargetInfo determined from a combination of all the Functions and the module we run into two self contradictory use-cases
- I want to do runtime selection of a specific function, we should use the least capable target feature set for a per module relaxation decision.
- I want to run on a specific target architecture, we should use the target features of that arch/cpu for a per module relaxation decision.
As we can't tell which of these use-cases I think we should make the decision per function.