<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">I don't know about clang, but it should work for llvm.</div><div dir="ltr"><br></div><div dir="ltr">On Thu, Jan 10, 2019, 14:54 Leonard Chan <<a href="mailto:leonardchan@google.com">leonardchan@google.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">@Jacob Lifshay<br>
<br>
In the case of the TypePrinter though, is there a way to access<br>
ASTContext? Part of my dilemma is that for diagnostics that simply<br>
print the type or the qualifiers, there doesn't seem to be an<br>
established way to access Context so I wouldn't be able to access this<br>
mapping. I'm thinking either this will require some refactoring of how<br>
types are printed to expose ASTContext or perhaps Qualifiers could be<br>
changed somehow such that the 23 bits allocated for the address space<br>
could instead point to some representation of an address_space that in<br>
turn could represent either a string or integer.<br>
<br>
- Leonard<br>
<br>
On Thu, Jan 10, 2019 at 2:21 PM Leonard Chan <<a href="mailto:leonardchan@google.com" target="_blank" rel="noreferrer">leonardchan@google.com</a>> wrote:<br>
><br>
> +<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
><br>
> On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" target="_blank" rel="noreferrer">programmerjake@gmail.com</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
> > Jacob Lifshay<br>
> ><br>
> > On Thu, Jan 10, 2019, 13:54 Leonard Chan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a> wrote:<br>
> >><br>
> >> 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></div></div>