GCNHazardRecognizer fails to identify hazards that are in and around bundles. This patch allows the hazard recognizer to consider bundled instructions in both scheduler and hazard recognizer mode. We ignore “bundledness” for the purpose of detecting hazards and examine the instructions individually.
Details
- Reviewers
arsenm msearles rampitec - Commits
- rZORGdcd805ca7ee7: [AMDGPU] Check MI bundles for hazards
rZORG40c5e9a5c502: [AMDGPU] Check MI bundles for hazards
rGdcd805ca7ee7: [AMDGPU] Check MI bundles for hazards
rG40c5e9a5c502: [AMDGPU] Check MI bundles for hazards
rG8a3d3a9af6f0: [AMDGPU] Check MI bundles for hazards
rL360199: [AMDGPU] Check MI bundles for hazards
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 31416 Build 31415: arc lint + arc unit
Event Timeline
Can you add a test for one of the hazards which do not expire and have no max waitstaits? Such as hazards from smem-war-hazard.mir for example.
Granted we do not do it today, but you can write a bundle with such instructions manually.
llvm/lib/Target/AMDGPU/SIInstrInfo.cpp | ||
---|---|---|
1172 | I do not like code duplication here. Can you call one from another? |
llvm/lib/Target/AMDGPU/SIInstrInfo.cpp | ||
---|---|---|
1172 | At first glance having the standard insertWaitStates call the instr_iterator version seems to break a bunch of tests. I can just add a function to insert noop's in bundles in GCNHazardRecognizer instead. |
Can you add a separate test file for cases where a hazard was hidden by a bundle, and another for where the hazard is inside the bundle?
There is no reason to split two test files.
For the test itself, could you please add one more. You have test where hazard instruction follows bundle. Can you add the same, where it is in bundle, and another one precedes it? Thanks!
Sorry, I'm not sure I understand exactly what you mean. Do you want a hazard instruction in a bundle with another hazard instruction preceding it?
I do not like code duplication here. Can you call one from another?