[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> On Aug 2, 2018, at 5:28 PM, Leonard Chan <leonardchan at google.com> wrote:
> 
> Ok. So we will no longer use the pragma. We will instead opt for your
> suggestion of printing the macro. So the new goals are now:
> 
> - Having address_space() accept strings in addition to integers to
> represent unique address spaces

Is this still important if you get the diagnostic improvement?  If you were declaring address
spaces somehow, this seems fine, but I don't really want to make address_space("whatever")
implicitly declare an address space with specific semantics when it's not hard to imagine
wanting that for other purposes in the future.

> - Changing the type printer to print the macro instead of the whole
> attribute if the attribute was passed a string instead of an int.

I don't know that the latter needs to be restricted; it seems like a nice usability improvement
for all address-space users.

John.

> On Thu, Aug 2, 2018 at 10:42 AM John McCall <rjmccall at apple.com> wrote:
>> 
>>> 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.