[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> 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.

- 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.

John.