KhronosGroup / KhronosGroup/OpenCL-Docs
Suggestion: pragma to control generic address space with __opencl_c_generic_address_space
- Dominant language
- Python
- Stars
- 420
- Forks
- 131
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
I was thinking whether a pragma could be useful that would enable or disable generic address space on target that supports generic address space. The idea would be to avoid conversions to generic where it is not needed.
Example 1:
```
void foo(int* ptr); // this means generic int*
void bar() {
int i;
foo(&i); // &i is converted to pointer to generic AS
}
```
Example 2:
```
#pragma OpenCL generic_address_space : disable
void foo(int* ptr); // this means int*
void bar() {
int i;
foo(&i); // &i is passes as pointer to private address space
}
```
In Example 1 pointer to `i` is first converted to generic address space before passed into `foo`. Example 2 demonstrates how the pragma can be used to avoid the conversion (this essentially defaults to OpenCL 1.2 behavior). Presumably, most of code would use private address space objects, and therefore it might be convenient to have a way to control such implicit conversions to generic address space in sections that only operate on private address space objects. Of course, alternatively private address space can be specified manually but this ends up quite verbose.
Note that this should be cheap to implement once we provide optionality for generic address space by splitting it into a feature.
FYI, pragma would only control implicit conversion, the builtin functions for converting the address spaces or overload of builtin functions in generic address space wouldn't be affected by the pragma.
Contributor guide
Research direction
Start by reviewing the issue's examples and the existing __opencl_c_generic_address_space feature semantics. Determine the intended pragma behavior for implicit conversions while preserving explicit conversions and generic-address-space builtin overloads. Done requires an agreed specification for the pragma, rather than only an implementation approach.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100