It turns out we can codegen these on targets without flat addressing,
although the runtime probably didn't put anything useful there. The
proper diagnostic would be to disallow flat pointer uses or languages
with them, not this one edge case. Allows removing one of the special
cases requiring subtarget support in the device libraries.
Details
- Reviewers
yaxunl b-sumner JonChesterfield Joe_Nash - Group Reviewers
Restricted Project
Diff Detail
Unit Tests
Event Timeline
clang/test/CodeGenOpenCL/builtins-amdgcn-flat-address-space.cl | ||
---|---|---|
8 | What part of the toolchain is responsible for forbiding flat pointers on unsupported targets? |
clang/test/CodeGenOpenCL/builtins-amdgcn-flat-address-space.cl | ||
---|---|---|
8 | The frontend should just error on languages with flat pointers. Really we should just implement software flat pointers, it wouldn’t be difficult and might only require minimal driver cooperation if any |
clang/test/CodeGenOpenCL/builtins-amdgcn-flat-address-space.cl | ||
---|---|---|
8 | Ok, I just want to ask if that is in place or should be in place before this patch lands. So we don't accidentally convert a compile time error into a runtime error. Otherwise LGTM. |
clang/test/CodeGenOpenCL/builtins-amdgcn-flat-address-space.cl | ||
---|---|---|
8 | In practice you’ll be failing to select all over on regular code long before you see this predicate |
What part of the toolchain is responsible for forbiding flat pointers on unsupported targets?