[cfe-dev] address_space pragma

[Leonard Chan via cfe-dev]

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