llvm dev - Jan 2019 - Proposal for string keys for address_space

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

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>

+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