Currently, CodeGen passes like LiveDebugValues work out whether DBG_INSTR_REF or DBG_VALUE instructions are being used for variable locations by examining the current optimisation level, and other attributes of the function. The assumption is that, by examining the function and optimisation level, you can work out later which flavour was used. Unfortunately this isn't always true, as reported in https://github.com/llvm/llvm-project/issues/57997 , things like opt-bisect-limit break this assumption because the optimisation level can change. When it does, the result is usually assertion failures.
To fix this, make "instruction referencing" an attribute of a MachineFunction -- it's simplest to just store whether or not the function was generated with DBG_INSTR_REF or not in a Boolean, and use that flag as the source-of-truth, rather than try to hack around this any further. This patch adds that flag to the MachineFunction (and MIR) parser, and adds the flag to the existing instruction referencing tests. As a result of this, we can un-plumb some flags out of SelectionDAG/FastISel that effectively implement the same thing. It still makes sense for InstrEmitter to hold a local copy of the are-we-using-instr-ref-flag as it checks it quite frequently.
The test changes are unremarkable; however this change means we can't feed the same MIR into both flavours of LiveDebugValues and expect to get legitimate outputs. As a result, I've duplicated three tests, to have instr-ref and DBG_VALUE versions:
- entry-value-of-modified-param.mir
- kill-entry-value-after-diamond-bbs.mir
- live-debug-values-bad-transfer.mir
Additionally there are two tests where I've just deleted the RUN lines for DBG_VALUE-behaviours and not duplicated the test:
- single-assign-propagation.mir: this test is checking that a performance-optimisation in InstrRefBasedLDV actually behaves correctly, there's nothing interesting about the way it passes through VarLocsBasedLDV. The DBG_VALUE-based check lines were only in there to provide a comparison with how VarLocBasedLDV behaved, I don't believe we actually need to be testing them.
- stack-coloring-dbg-phi.mir: this test exists because stack coloring changed codegen when it saw DBG_PHI instructions, it doesn't actually need a DBG_VALUE run line.
(retitled as this got submitted 5 seconds too early X_X)
nit: I think it would make sense to move this to line 203, underneath YamlMF.HasEHFunclets = MF.hasEHFunclets();