[cfe-dev] [llvm-dev] Proposal for string keys for address_space

[Jacob Lifshay via cfe-dev]

I don't know about clang, but it should work for llvm.

On Thu, Jan 10, 2019, 14:54 Leonard Chan <leonardchan at google.com wrote:

> @Jacob Lifshay
>
> In the case of the TypePrinter though, is there a way to access
> ASTContext? Part of my dilemma is that for diagnostics that simply
> print the type or the qualifiers, there doesn't seem to be an
> established way to access Context so I wouldn't be able to access this
> mapping. I'm thinking either this will require some refactoring of how
> types are printed to expose ASTContext or perhaps Qualifiers could be
> changed somehow such that the 23 bits allocated for the address space
> could instead point to some representation of an address_space that in
> turn could represent either a string or integer.
>
> - Leonard
>
> On Thu, Jan 10, 2019 at 2:21 PM Leonard Chan <leonardchan at google.com>
> wrote:
> >
> > +cfe-dev at lists.llvm.org
> >
> > On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> > >
> > > Stash a lookup table from integers to strings in Context and
> dynamically allocate integers for new strings. You can then keep integers
> in most of the code, writing/displaying strings for the integers with an
> entry in the table when writing to files or displaying.
> > >
> > > Jacob Lifshay
> > >
> > > On Thu, Jan 10, 2019, 13:54 Leonard Chan via llvm-dev <
> llvm-dev at lists.llvm.org wrote:
> > >>
> > >> Hello,
> > >>
> > >> We would like to propose a way for improving the diagnostics for
> > >> address_space by being able to pass strings as an argument to it
> > >> instead of just an integer. This was initially proposed before
> > >> (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but
> > >> did not focus on it at the time.
> > >>
> > >> Reasoning:
> > >> Clang's __attribute__((address_space(...))) feature uses an arbitrary
> > >> integer as the discriminator of address spaces. This is effectively a
> > >> global name space of integers in an API. The meaningless integers are
> > >> used in diagnostics, which is not very informative. Moreover, the
> > >> maintenance of the integer assignments is error-prone. It would be
> > >> better if this could be a string rather than an integer. It's easy
> > >> enough to pick string prefixes that distinguish the use in one part of
> > >> an API from others in separately-maintained APIs, just as with symbol
> > >> name prefixes in C APIs.
> > >>
> > >> Goals:
> > >> - Allow for address_space to accept strings so various APIs do not
> > >> need to share the same global name space of integers
> > >> (address_space("API1") != address_space("API2"))
> > >> - Print the string argument instead of an integer if address_space is
> > >> provided with a string for more understandable error messages.
> > >>
> > >> (Possible) Implementation:
> > >> Off the top of my head, it seems that a large chunk of this would be
> > >> changing how address spaces are managed. Currently, it seems that all
> > >> address_spaces are limited to just integers with a few spaces reserved
> > >> for OpenCL and CUDA under the LangAS enum. I'm thinking that LangAS
> > >> itself could be a base class with 2 different subclasses that take
> > >> either integers or strings and when storing them in a qualifier, part
> > >> of the address space mask could be dedicated to indicating if this
> > >> LangAS is a string or integer. The only thing I can't think of is how
> > >> printing the AS would work in a diagnostic since, based off the
> > >> existing TypePrinter/Qualifiers::print() method, I do not think I
> > >> would be able to store a reference back to some mapping of addr spaces
> > >> to strings since it seems that the Qualifiers class is meant to be 32
> > >> bits long and passed by value.
> > >>
> > >> I was going to come up with a proof of concept in the meantime, but
> > >> wanted to ask sooner to see if anyone had ideas on this or ideas on
> > >> how this could be implemented. Any feedback is welcome and I don't
> > >> mind answering questions.
> > >>
> > >> Thanks,
> > >> Leonard
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> llvm-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190110/822e20d4/attachment.html>