<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">Jacob Lifshay</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019, 13:54 Leonard Chan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
We would like to propose a way for improving the diagnostics for<br>
address_space by being able to pass strings as an argument to it<br>
instead of just an integer. This was initially proposed before<br>
(<a href="http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html</a>) but<br>
did not focus on it at the time.<br>
<br>
Reasoning:<br>
Clang's __attribute__((address_space(...))) feature uses an arbitrary<br>
integer as the discriminator of address spaces. This is effectively a<br>
global name space of integers in an API. The meaningless integers are<br>
used in diagnostics, which is not very informative. Moreover, the<br>
maintenance of the integer assignments is error-prone. It would be<br>
better if this could be a string rather than an integer. It's easy<br>
enough to pick string prefixes that distinguish the use in one part of<br>
an API from others in separately-maintained APIs, just as with symbol<br>
name prefixes in C APIs.<br>
<br>
Goals:<br>
- Allow for address_space to accept strings so various APIs do not<br>
need to share the same global name space of integers<br>
(address_space("API1") != address_space("API2"))<br>
- Print the string argument instead of an integer if address_space is<br>
provided with a string for more understandable error messages.<br>
<br>
(Possible) Implementation:<br>
Off the top of my head, it seems that a large chunk of this would be<br>
changing how address spaces are managed. Currently, it seems that all<br>
address_spaces are limited to just integers with a few spaces reserved<br>
for OpenCL and CUDA under the LangAS enum. I'm thinking that LangAS<br>
itself could be a base class with 2 different subclasses that take<br>
either integers or strings and when storing them in a qualifier, part<br>
of the address space mask could be dedicated to indicating if this<br>
LangAS is a string or integer. The only thing I can't think of is how<br>
printing the AS would work in a diagnostic since, based off the<br>
existing TypePrinter/Qualifiers::print() method, I do not think I<br>
would be able to store a reference back to some mapping of addr spaces<br>
to strings since it seems that the Qualifiers class is meant to be 32<br>
bits long and passed by value.<br>
<br>
I was going to come up with a proof of concept in the meantime, but<br>
wanted to ask sooner to see if anyone had ideas on this or ideas on<br>
how this could be implemented. Any feedback is welcome and I don't<br>
mind answering questions.<br>
<br>
Thanks,<br>
Leonard<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>