[cfe-dev] [llvm-dev] Proposal for string keys for address_space
Leonard Chan via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 10 14:21:23 PST 2019
+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:
>> 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.
>> 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.
>> - 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.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the cfe-dev