<div dir="ltr">> <span style="font-size:12.8px">My point was that the DataLayout isn't available inside the LLParser and the BitcodeReader, up until the point when it has been parsed. So I would not say "always available".</span><br style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I have noticed this. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">N</span><span style="font-size:12.8px">ormally, the frontend compilation adds functions, and them emits some form of code. There are no issues with normal .o or .s compilation, but if we emit IR, we lose the address space information because it is not actually a part of the textual IR form.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The standard LLParser process has no data layout available until the end of the process (because we create an empty temporary module for parsing).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Because of both of these problems, the best way to implement this is modify the textual IR form to support address space attributes on function declarations.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I think the whole idea from Dylan was to do this as a fixup after LLParser/BitcodeReader</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Originally, that was the only workable solution I could come up with, but I think the solution Hal suggested is better.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">As I understand it:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">* New functions created by the frontend will default to the address space specified in the DataLayout</span></div><div><span style="font-size:12.8px">* When these functions get lowered to LL, we emit the address space on the function like 'addrspace 1' if it is not the default address space 0</span></div><div><span style="font-size:12.8px">* When parsing, all functions will either have no addrspace attribute and default to '0', or take the addrspace specified</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This will let frontends specify explicit address spaces manually (which would support </span>Mikael and others usecases), and also keep track of the address space throughout the pipeline so that we don't make any incorrect assumptions of the space.</div><div><br></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 5:33 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 07/13/2017 12:25 PM, Björn Pettersson A wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: Hal Finkel [mailto:<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>]<br>
Sent: den 13 juli 2017 16:01<br>
To: Björn Pettersson A <<a href="mailto:bjorn.a.pettersson@ericsson.com" target="_blank">bjorn.a.pettersson@ericsson.c<wbr>om</a>>; David Chisnall<br>
<<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>>; Dylan McKay <<a href="mailto:me@dylanmckay.io" target="_blank">me@dylanmckay.io</a>><br>
Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Carl Peto <<a href="mailto:carl.peto@me.com" target="_blank">carl.peto@me.com</a>><br>
Subject: Re: [llvm-dev] RFC: Harvard architectures and default address<br>
spaces<br>
<br>
On 07/13/2017 05:38 AM, Björn Pettersson A via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My experience of having the address space for functions (or function<br>
</blockquote>
pointers) in the DataLayout i that when the .ll file is parsed we need to parse<br>
the DataLayout before any function declarations. That is needed because we<br>
want to attribute the functions with correct address space (according to<br>
DataLayout) when inserting them in the symbol table. An alternative would<br>
be to update address space info for functions after having parsed the<br>
DataLayout.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is the DataLayout normally used when parsing the .ll file (or .bc)? Or would<br>
</blockquote>
this be the first case of doing that?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it guaranteed that DataLayout is specified/parsed before function<br>
</blockquote>
declaration, or that the DataLayout specification is context sensitive and only<br>
is valid for the following declarations?<br>
<br>
The DataLayout is a required part of the .ll/.bc file. In the .ll file<br>
(*), it's the part of the module that looks like this:<br>
<br>
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32<wbr>:64-S128"<br>
<br>
it is global to the entire module and always available.<br>
</blockquote>
My point was that the DataLayout isn't available inside the LLParser and the BitcodeReader, up until the point when it has been parsed. So I would not say "always available".<br>
<br>
Both LLParser and BitcodeReader is for example using getAddressSpace(), both directly and maybe also indirectly through different interfaces (perhaps not on function pointers though). My concern is that maybe the incorrect address space will be used while parsing, and then it might be hard to find all places to fixup at a later stage. when having parsed the DataLayout and finding out what the default address space really is.<br>
Or if there is some undocumented(?) rule that the DataLayout always comes before function declarations in the ll/bc file, then all functions can get the default address space attribute directly (as indicated by the DataLayout) when being parsed.<br>
<br>
I think the whole idea from Dylan was to do this as a fixup after LLParser/BitcodeReader. I.e not trying to lookup a functions address space already when parsing the function declaration. So then the rule would be - do not use Pointer<Function>::getAddressS<wbr>pace(), or PointerType::get() etc. during ll/bc parsing because it might give the wrong result. Maybe it is possible to assert on that?<br>
<br>
We could of course give functions some kind of undefined address space value when parsing ll/bc and adding functions to the symbol table. That might help us catch situations when someone tries to fetch the address space for a function pointer before the set-default-address-space-as-g<wbr>iven-by-datalayout-on-all-func<wbr>tions pass has executed.<br>
</blockquote>
<br></div></div>
I understand your point. We need to extend the syntax to enabling tagging functions with addressspaces directly (i.e. as a function attribute). DataLayout can't, as you noted, and shouldn't, be used to adjust defaults during parsing. The point of the defaults in DataLayout is to provide some way to supply correct defaults should optimizations need them.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Hal</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(*) It is true that you can write tests without specifying one of these,<br>
but in such cases, you just get the builtin default. For all real cases<br>
you'll need to have a target-appropriate DataLayout string.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What if there are several address spaces for functions? Or is that a silly<br>
</blockquote>
thing that no one ever will use? Having the address space specified in the<br>
DataLayout would be insufficient, since we would need to attribute the<br>
functions separately, right?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do not say that having the info in the DataLayout is a totally bad idea (since<br>
</blockquote>
our out-of-tree target is using that trick), but I think it might impose some<br>
problems as well. And perhaps it isn't the most general solution.<br>
<br>
If different functions might be in different address spaces, you'll need<br>
some other mechanism to set the address space (as a single default won't<br>
suffice). You might use source-level function attributes, for example.<br>
<br>
-Hal<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/Björn<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists<wbr>.llvm.org</a>] On Behalf Of<br>
</blockquote></blockquote>
David<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chisnall via llvm-dev<br>
Sent: den 12 juli 2017 17:26<br>
To: Dylan McKay <<a href="mailto:me@dylanmckay.io" target="_blank">me@dylanmckay.io</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Carl Peto <<a href="mailto:carl.peto@me.com" target="_blank">carl.peto@me.com</a>><br>
Subject: Re: [llvm-dev] RFC: Harvard architectures and default address<br>
spaces<br>
<br>
On 11 Jul 2017, at 23:18, Dylan McKay via llvm-dev <llvm-<br>
</blockquote></blockquote>
<a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Add this information to DataLayout and to use that information in<br>
</blockquote></blockquote>
relevant places.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This sounds like a much better/cleaner idea, thanks!<br>
</blockquote>
I’d suggest taking a look at the alloca address space changes, which were<br>
recently added based on a cleaned-up version of our code. We have a<br>
</blockquote></blockquote>
similar<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
issue (function and data pointers have the same representation for us,<br>
</blockquote></blockquote>
but<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
casting requires different handling[1]) and have considered adding<br>
</blockquote></blockquote>
address<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
spaces to functions.<br>
<br>
David<br>
<br>
[1] Probably not relevant for this discussion, but if anyone cares: in our<br>
</blockquote></blockquote>
world<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
we have 128-bit fat pointers contain base, bounds and permissions, and<br>
</blockquote></blockquote>
that<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
64-bit pointers that are implicitly relative to one of two special fat pointer<br>
registers, one for code and one for data. We must therefore handle 64-<br>
</blockquote></blockquote>
bit to<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
128-bit pointer casts differently depending on whether we’re casting<br>
</blockquote></blockquote>
code or<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
data pointers. We currently do this with some fairly ugly hacks, but being<br>
able to put all functions in a different AS would make this much easier for<br>
</blockquote></blockquote>
us.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
--<br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</blockquote></blockquote>
<br>
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</div></div></blockquote></div><br></div>