The old syncscope parameter never really worked correctly, but
effectively gave "workgroup" scope. Use something faster than system
but more correct than before.
Details
- Reviewers
rampitec sameerds nhaehnle jdoerfert tianshilei1992 - Group Reviewers
Restricted Project
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
60,040 ms | x64 debian > MLIR.Examples/standalone::test.toy |
Event Timeline
What is the "old syncscope parameter" mentioned in the change description? In the actual change and the lit tests, the default "system" scope is being changed to "agent", which superficially looks like an incorrect change.
In the deleted intrinsic. There was an integer syncscope argument which was never actually used. This just needs to try emulating the old intrinsic behavior
Before the change that dropped the intrinsic, the legalizer looks like it was translating the syncscope parameter from the intrinsic to the emitted atomic. Then the dropping change upgrade the scope to the default system scope. Then in what sense was it not previously used? If the old behaviour produced atomics that only worked in workgroup scope, does that mean that even now, an LLVM program that uses atomic instructions with system scope is not guaranteed to work?
Also, should there be a .bc test demonstrating the auto-upgrade?
It wasn't. The MachineMemOperand properties come from getTgtMemIntrinsic and never read these. Switching the implementation fixed bugs from assuming workgroup scope, there weren't enough waits.
Then the dropping change upgrade the scope to the default system scope. Then in what sense was it not previously used? If the old behaviour produced atomics that only worked in workgroup scope, does that mean that even now, an LLVM program that uses atomic instructions with system scope is not guaranteed to work?
Switching to atomicrmw fixed all the non-system scope cases. This fixes it so you still get the instruction through the intrinsic after D157437 (although unfortunately you lose that if you upgraded with a previous version), but system scope would continue to not work.
Also, should there be a .bc test demonstrating the auto-upgrade?
This is the "bc" test. All the intrinsic autoupgrade tests work by assembling and then disassembling text bitcode, there's no encoding change being tested