[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> On Aug 1, 2018, at 3:19 PM, Leonard Chan via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> We would like to propose a new pragma that changes the error message
> produced when using pointers with different address spaces. For
> example, given the following:
> 
> ```
>  1 #define SPACE1 __attribute__((address_space(1)))
>  2 #define SPACE2 __attribute__((address_space(2)))
>  3
>  4 void func(char SPACE1 *a){}
>  5
>  6 int main() {
>  7   char SPACE2 *a;
>  8   func(a);
>  9 }
> ```
> 
> The following error is produced:
> 
> ```
> error: passing '__attribute__((address_space(2))) char *' to parameter
> of type '__attribute__((address_space(1))) char *' changes address
> space of pointer
> ```
> 
> We would like to propose a pragma that would allow for binding an
> address_space to a string, and a list of other attributes used with
> address_space, such that the error will instead print the string
> passed instead of the whole attribute. That is, this would be dumped
> instead:
> 
> ```
> error: passing 'SPACE2 char *' to parameter of type 'SPACE1 char *'
> changes address space of pointer
> ```
> 
> from the following code
> 
> ```
>  1 #pragma clang address_space "SPACE1"
>  2 #pragma clang address_space "SPACE2"
>  3 #define SPACE1 __attribute__((address_space("SPACE1")))
>  4 #define SPACE2 __attribute__((address_space("SPACE2")))
>  5
>  6 void func(char SPACE1 *a){}
>  7
>  8 int main() {
>  9   char SPACE2 *a;
> 10   func(a);
> 11 }
> ```
> 
> The proposed usage would be along the lines:
> `#pragma clang address_space <string> <variable-attributes>`
> 
> where the address_space pragma accepts a string as the first argument
> to indicate what gets printed in the error and a list of other
> attributes that one would want to pair with address_space.
> 
> This would also be useful with codebases that use Sparse
> (http://sparse.wiki.kernel.org/), a static analyzer used on the Linux
> kernel that uses special annotations to convey information about
> certain data types. One such usage is with `__user` which is defined
> as `__attribute__((noderef, address_space(1)))`, where pointers
> declared with `__user` complain if they are dereferenced or it’s used
> for address spaces that aren’t address_space(1).
> 
> In the case of tools that use Sparse, instead of printing
> `__attribute__((noderef, address_space(1))) void *` for the __user
> macro, `__user void *` would be printed instead when using `#pragma
> clang address_space "__user" noderef`.
> 
> The changes in this patch would include (though I could naively be
> missing some other stuff):
> - Adding the address_space pragma which will require some internal
> mapping of the string to address_space and a list of other attributes
> used with it.
> - Changing the address_space attribute to accept strings in addition
> to integers. Accepting a string will map to whatever attributes were
> used in the pragma while accepting an int defaults to the regular
> address_space behavior.
> 
> For now we intend to use this primarily with address_space but are
> open to feedback on other ways we can improve this or expand on the
> usage for other attributes.

Is your expectation that these address spaces will be exclusively used for diagnostics?
Should they support promotions between address spaces?

Do you have an idea of what the "variable attributes" would look like?

I am somewhat concerned about introducing a rather significant new language feature using pragmas.

John.