Backend defaults to setting WGP mode to 0 or 1 depending on the cumode
feature. For PAL clients we want PAL to set this mode.
Adding check to prevent the backend overriding whatever the front end has set.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 33719 Build 33718: arc lint + arc unit
Event Timeline
Needs test
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | This seems like a workaround. Why isn't PAL setting what it wants initially and overriding it later? |
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | I'm also thinking this should be an attribute rather than a sub target feature |
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | Not sure what you're getting at here. We could work around this by always setting the CuMode sub target feature in any PAL front-end - then the value passed in from PAL would always be honoured, but that seems more hacky to me. We can change CuMode to be an attribute rather than sub target feature as a separate change, but that pre-exists this work. I'll put a test together if we can agree an approach. |
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | Always setting the subtarget feature does seem like the right approach to me. Changing it to a target attribute may be something to consider. It's one of those non-trivial things because it would have to be added to all functions, not just the kernel entry point, but... |
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | This seems like something we should handle consistently for all OS types, not just AMDPAL |
lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp | ||
---|---|---|
970–974 | I think I'll go with always setting the sub target feature for now, so I'll abandon this change. |
I might revisit this one - setting cumode seems messy to enable driver control of the WGP setting, but seems the most pragmatic at the moment.
This seems like a workaround. Why isn't PAL setting what it wants initially and overriding it later?