We want special handing for IGLP instructions in the scheduler but they
should still be treated like they have side effects by other passes. Add
a target hook to the ScheduleDAGInstrs DAG builder so that we have more
control over this.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/CodeGen/ScheduleDAGInstrs.cpp | ||
---|---|---|
537 | I don't understand why you need to special case these. Isn't this more or less the same as removing hasSideEffects from the instruction? Could you achieve the same thing by using a pseudo memory operand that doesn't alias anything the instruction reads and writes from? |
llvm/lib/CodeGen/ScheduleDAGInstrs.cpp | ||
---|---|---|
537 | Should the intrinsic have sideeffects in that case? We would need some special handling in isel if there is a mismatch between hasSideEffects between the intrinsics and the MachineInstrs. |
If the approach is agreed upon, it LGTM.
FWIW, MI.hasUnmodeledSideEffects seems to be used to stop other passes in CodeGen. Even if these passes are currently irrelevant to the IGLP, we will need to be sure any future reliance on this accounts for IGLP (if we remove sideeffects from MI)
llvm/lib/Target/AMDGPU/GCNSchedStrategy.cpp | ||
---|---|---|
1540 | can you combine the logic? | |
1559 | ditto |
llvm/lib/CodeGen/ScheduleDAGInstrs.cpp | ||
---|---|---|
537 | HasSideEffects is a catch all for unmodeled properties. Selectively ignoring it implies there should be a different property to express this constraint. Given that side effects aren’t really enough to prevent pure arithmetic code motion in the original IR, it seems to me it shouldn’t have side effects |
Something is wrong with the instruction or intrinsic properties, this shouldn't require special casing
I don't understand why you need to special case these. Isn't this more or less the same as removing hasSideEffects from the instruction? Could you achieve the same thing by using a pseudo memory operand that doesn't alias anything the instruction reads and writes from?