<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
I think this is a wider problem to solve. Adding explicit semantic to address spaces is something we would indeed like to see in LLVM IR. Neil Hickey (in CC) was touching this in his LLVM Dev Meeting talk: <a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk8" class="OWAAutoLink">https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk8</a></div>
<div style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Justin Lebar <jlebar@google.com><br>
<b>Sent:</b> 11 January 2019 17:04<br>
<b>To:</b> Anastasia Stulova<br>
<b>Cc:</b> Leonard Chan; Jacob Lifshay; nd; Clang Dev<br>
<b>Subject:</b> Re: [cfe-dev] [llvm-dev] Proposal for string keys for address_space</font>
<div> </div>
</div>
<div>
<div dir="ltr">I don't (at the moment) have an opinion on the implementation, but to the broader principle of improving the representation of these address spaces, this sounds like it would scratch an itch of mine. In XLA nvptx backend, passing around these
integer address spaces has lead to a few near-bugs, and when reading nvptx IR, it would be super-nice if I could somehow be reminded of what address space 5 is.
<div><br>
</div>
<div>-Justin</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr">On Fri, Jan 11, 2019 at 6:21 AM Anastasia Stulova via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div id="x_gmail-m_-7589841585288742012divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p style="margin-top:0px; margin-bottom:0px">Just to understand better on the language side do you suggest to keep integer value for an attribute too? I think for the legacy or speed reason some users might still prefer integers.</p>
<p style="margin-top:0px; margin-bottom:0px"><br>
</p>
<p style="margin-top:0px; margin-bottom:0px">In Clang AST address spaces are stored in Qualifiers as integer values. So you would need some conversion and a map from string to integers to be stored. ASTContext could be a good place to store the map since it's
accessible during all the different phases - parsing, sema, codegen.</p>
<p style="margin-top:0px; margin-bottom:0px"><br>
</p>
<p style="margin-top:0px; margin-bottom:0px">Btw, are you suggesting this only for Clang? Other than emitting the address space map (as metadata perhaps?) in IR, are there any other changes you plan?</p>
<p style="margin-top:0px; margin-bottom:0px"><br>
</p>
<p style="margin-top:0px; margin-bottom:0px">Cheers,</p>
<p style="margin-top:0px; margin-bottom:0px">Anastasia <br>
</p>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block; width:98%">
<div id="x_gmail-m_-7589841585288742012divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>>
on behalf of Jacob Lifshay via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Sent:</b> 10 January 2019 23:13<br>
<b>To:</b> Leonard Chan<br>
<b>Cc:</b> llvm-dev; Clang Dev<br>
<b>Subject:</b> Re: [llvm-dev] Proposal for string keys for address_space</font>
<div> </div>
</div>
<div>
<div dir="auto">
<div>
<div class="x_gmail-m_-7589841585288742012x_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" target="_blank">leonardchan@google.com</a> wrote:<br>
</div>
<blockquote class="x_gmail-m_-7589841585288742012x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); 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" rel="noreferrer" target="_blank">leonardchan@google.com</a>> wrote:<br>
><br>
> +<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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>
</div>
</div>
</div>
</div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</body>
</html>