Translate llvm.trap intrinsic to AMDGPU machine instruction(s).
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 46384 Build 48816: arc lint + arc unit
Event Timeline
Should also handle debug trap, but that may be a separate patch
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp | ||
---|---|---|
1114–1131 | I would factor all of this into a helper function. This is also basically identical to AMDGPULegalizerInfo::loadInputValue, so you could just move this handling into the legalizer | |
1117 | s/unsigned/Regisster | |
llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-trap.ll | ||
1 | This isn't an irtranslator, so it shouldn't have it in the name. I would also expect it to be possible to share the test with the DAG tests | |
39–40 | Remove the dead code | |
42 | Should also have a test where this is used inside a non-entry block, and in a case that uses the stack. |
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp | ||
---|---|---|
1114–1131 | I think, there is no straightforward way to use Legalizer within IRTranslator? I can do STI.getLegalizerInfo(), but it won't help to call AMDGPULegalizerInfo::loadInputValue() as it is not a general virtually callable API, but, it is a kind of helper function specific to AMDGPU. I again need to explicitly cast STI.getLegalizerInfo() into AMDGPULegalizerInfo*, in order to loadInputValue(). I am not sure, if it is something worth doing it here. |
llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp | ||
---|---|---|
1114–1131 | The IRTranslator isn't involved. The decision to put this in the legalizer or in selection is somewhat arbitrary. We handle the other intrinsics in the legalizer now, so you might as well put this there as well. |
Based on the review comments by arsenm, I have moved handling of trap and debugtrap intrinsics to Legazizer, and submitted a new Phabricator review request - https://reviews.llvm.org/D74688. Hence closing this review request.
You could also have just updated this one with a new diff, instead of creating a separate review. Splitting the review usually makes it harder to track
Yes, I definitely agree. That is the right way to make any review changes. I initially thought of doing the same. But, later created new review because I thought of handling both trap and debug-trap intrinsics together. I will avoid it in next time on-wards.
s/unsigned/Regisster