[cfe-dev] address_space pragma

[Leonard Chan via cfe-dev]

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
- Changing the type printer to print the macro instead of the whole
attribute if the attribute was passed a string instead of an int.
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.