The existing code wasn't getting the subtarget info from the fragment, so the current status of RVC would be ignored. This would cause a crash for the new test case when the target then reported it couldn't write the requested number of code alignment bytes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp | ||
---|---|---|
610–611 | This one wasn't needed to fix the crash but, presumably, this check should also be fixed? |
This patch makes sense to me and I think it is a correct fix.
In LLVM MC, the STI's feature bits is not mutable, it was determined by the command line before parsing the file. And to deal with directives like .option rvc, the Parser maintains an STI and replaces it with a new STI when the subtarget extensions were enabled or disabled. So we need to use MCAlignFragment's STI which is generated using the replaced STI by the parser. Is my understanding correct?
llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp | ||
---|---|---|
610–611 | I agree this check should also be fixed. And if it would be better to have a test that can test this fix? |
This patch makes sense to me and I think it is a correct fix.
In LLVM MC, the STI's feature bits is not mutable, it was determined by the command line before parsing the file. And to deal with directives like .option rvc, the Parser maintains an STI and replaces it with a new STI when the subtarget extensions were enabled or disabled. So we need to use MCAlignFragment's STI which is generated using the replaced STI by the parser. Is my understanding correct?
I wouldn't focus too much on it being mutable or not. I think the important point is that because we aren't doing everything in a single pass we need to track the state of the flags at various points in the assembly file. Which we do, but apparently we weren't then using the saved state for those locations, just the global state. Being mutable (and not copying it) would only help if we were doing everything in a single pass. At least that was my interpretation of the issue. Sorry to nitpick your explanation, I just wanted to clarify that point :) Broadly speaking I would say your explanation is correct.
Can we get this landed on time for backporting into 14.0.1? (it took me some time to address the review feedback because I was sick).
This one wasn't needed to fix the crash but, presumably, this check should also be fixed?