[llvm-dev] Proposal for string keys for address_space

[Jacob Lifshay via llvm-dev]

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/llvm-dev/attachments/20190110/24dafbfc/attachment.html>