<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: 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">
<p style="margin-top:0;margin-bottom:0">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:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">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:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Cheers,</p>
<p style="margin-top:0;margin-bottom:0">Anastasia <br>
</p>
<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> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Jacob Lifshay via llvm-dev <llvm-dev@lists.llvm.org><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_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="x_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>
</div>
</div>
</div>
</body>
</html>