[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> On Aug 2, 2018, at 12:55 PM, Leonard Chan <leonardchan at google.com> wrote:
> On Wed, Aug 1, 2018 at 8:09 PM John McCall <rjmccall at apple.com> wrote:
>> 
>> 
>> 
>>> On Aug 1, 2018, at 7:59 PM, Leonard Chan <leonardchan at google.com> wrote:
>>> 
>>> On Wed, Aug 1, 2018 at 4:27 PM John McCall <rjmccall at apple.com> wrote:
>>>> 
>>>>> On Aug 1, 2018, at 6:50 PM, Leonard Chan <leonardchan at google.com> wrote:
>>>>> 
>>>>>> Is your expectation that these address spaces will be exclusively used for diagnostics?
>>>>> 
>>>>> Yes. This will serve as a way of essentially shortening an attribute
>>>>> list in the diagnostic for address_space since this is what's useful
>>>>> to us for now, but we are open to expanding this to fit other use
>>>>> cases as long as we get this.
>>>>> 
>>>>>> Should they support promotions between address spaces?
>>>>> 
>>>>> We weren't planning on this. The idea is that each new address space
>>>>> created with this pragma will be a new address space disassociated
>>>>> from any previous one.
>>>> 
>>>> And these are supposed to work like actual language address spaces, right?
>>>> Which is to say, they're not interconvertible at all?  I'm a little confused about how
>>>> this fights into a code-analysis framework when it's actually a major semantic
>>>> change.
>>> 
>>> These are meant to work like regular address spaces, but instead of
>>> accepting an integer to represent a unique space, some unique
>>> serializable ID is given instead. That is in your code, you should be
>>> able to pass strings instead of integers to all instances you use the
>>> attribute address_space, assuming you declare the pragma beforehand,
>>> and you shouldn't have to change anything else.
>> 
>> Yes, I understood that.
>> 
>>> I could be missing something about address spaces, but my
>>> understanding was that they were for preventing usage of pointers from
>>> one space in another and all address spaces were unique.
>> 
>> Okay, so you do want them to function as actual address spaces.  And I can
>> understand why this is useful in the kernel.  I think I'm just surprised to hear this
>> called "static analysis"; it's much more like a language dialect that's fortunately
>> easy to disable with macros.  For example, if the kernel wanted to use this to
>> give __user pointers a different representation or use different code-generation
>> patterns for accesses to them, it could pretty easily do that using these annotations
>> and the right compiler support.
>> 
>> So, as I see it, the goals of the feature are:
>> 
>> - Arbitrary code can declare an address space nominally without worrying about
>>  having picked a unique number.  Definitely a win.
>> 
>> - The program can have all the benefits of a custom qualifier in terms of type-checking,
>>  and the compiler can be smart enough to just erase the address space when generating
>>  code.  (Conceivably it could erase it to some other attribute space.)  Also a clear win.
>> 
>> - The address space name will get preserved in diagnostics.  This one is questionable
>>  to me because it's only "preserved" in a really ugly way: the programmer wrote
>>  `__user`, and even with this feature, the diagnostic will be talking about
>>  `__attribute__((address_space("user")))`.  This is why I think you want to look into
>>  presenting the original macro if you can.
> 
> Oh it wouldn't be `__user` the macro that get's presented, it would be
> the string passed to address_space() that's printed. So in this
> example it would be "user", not `__user`.

It'll be __attribute__((address_space("user"))).  I don't think there are any diagnostics that
actually extract the argument to address_space and print that; they all just print the type,
and the type printer will expand the whole attribute because it doesn't know any better.

> I think it would feel
> awkward if we worked around this one special case where if we have an
> address_space attribute that accepted a string and was defined in a
> macro, then we would print the macro, otherwise the string. I'm not
> sure what overhead there is on that, but I believe the way the whole
> attribute gets printed is by just recording the start and end
> SourceLocation for the whole attribute, so instead we could just
> return the start and end SL of the string argument.

The type printer has multiple hacks dedicated to printing out types in a more
user-friendly way.  There are a lot of types where most users don't know about the
attributes that actually implement them; two examples that come to mind are vector
types and the ARC ownership qualifiers.  Making an effort to pretty-print a qualifier
would not be unprecedented.

>> - The attribute can automatically apply the optional attributes.  This part also seems
>>  poorly-motivated to me.  `__attribute__((address_space("user")))` is still an awful
>>  thing to write all over the place, so in practice you're always going to want to define
>>  a macro that programmers will use, and of course that macro can apply other attributes.
> 
>> I'll also repeat that I don't think you want do this with a pragma; I can imagine all sorts
>> of ways to extend this feature in the future, but jamming all that information after a #pragma
>> is very awkward, and you can't use the preprocessor inside a #pragma.  Consider
>> making it an `__address_space user` declaration instead, with some ad-hoc syntax inside
>> to describe the various properties of the address space.
> 
> Could you clarify on this `__address_space user` declaration? One of
> the things we would like is for a given address_space to always have a
> given list of attributes, but that could also be handled in the macro.

I was just sketching an alternative language design that I think works better than a pragma.
You're adding a language feature here; you have to do proper language design for it.

John.