[llvm-dev] Proposal for string keys for address_space

[Leonard Chan via llvm-dev]

+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