<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/28/2014 11:21 AM, Brandon Holt
wrote:<br>
</div>
<blockquote
cite="mid:47F37908-8BB1-44D7-BCD6-0E3413F6A148@cs.washington.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div style="word-wrap:break-word">
<div>I have since found many more places in Clang’s CodeGen that
doesn’t take into account AddrSpaceCast when implicitly
converting operands with BitCast. Is a better solution to
instead just make BitCast check if the address spaces are
different and apply an AddrSpaceCast instead? I made such a
change in `llvm/lib/IR/Instructions.cpp` (see attached patch).</div>
</div>
</blockquote>
I've thought of trying that, but I think that will just hide many
bugs. Most everywhere I've encountered that's trying to bitcast
between address spaces is a bug from using the default.<br>
<br>
<blockquote
cite="mid:47F37908-8BB1-44D7-BCD6-0E3413F6A148@cs.washington.edu"
type="cite">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>This seems like it misses the point of adding the
AddrSpaceCast, and breaks assumptions because when you insert
a BitCast you may or may not insert an AddrSpaceCast instead.
Perhaps the correct solution is to find all the cases in
Clang’s CodeGen where this may come up and ensure that we
handle them all correctly...</div>
</div>
</blockquote>
Yes. I haven't done as thorough of a search through the uses in
clang as I have in core LLVM for this.<br>
<br>
<blockquote
cite="mid:47F37908-8BB1-44D7-BCD6-0E3413F6A148@cs.washington.edu"
type="cite">
<div style="word-wrap:break-word">
<div><br>
</div>
</div>
<div style="word-wrap:break-word">
<br>
<div>
<div>On Jan 25, 2014, at 2:55 PM, Brandon Holt <<a
moz-do-not-send="true"
href="mailto:bholt@cs.washington.edu">bholt@cs.washington.edu</a>>
wrote:</div>
<br class="x_Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap:break-word">Bringing this to the
attention of the Clang list because that’s actually where
my problems exist.
<div><br>
</div>
<div>I’m working on using the “address_space” attribute
to delineate special pointers in a pass I’m working on.
This lets me intercept uses of these pointers and plug
in calls to my runtime wherever there’s a load/store or
other use. However, I’m having problems trying to call
methods on pointers with this attribute.</div>
<div><br>
</div>
<div>I ran into a CodeGen problem where
CodeGenFunction::EmitCall tried to `bitcast`an
addrspace(N)* and failed an assertion. The attached
patch is one possible fix, which is to use
`addrspacecast` if the address spaces are different,
otherwise just use `bitcast` as before. This has allowed
me to then write my own pass to replace these instances
with things from my runtime.</div>
<div><br>
</div>
<div>However, I have a new problem now: the Clang type
checker seems to choke converting between
`__attribute__((address_space(N))` annotated types and
const types, so that, though it allows me to call a
non-const method on an addrspace pointer, it issues a
compile error when I try to invoke a “const” method:</div>
<div><br>
</div>
<div style="font-size:11px"><font face="Menlo">struct Foo
{</font></div>
<div style="font-size:11px"><font face="Menlo"> void
bar() const { /* … */ }</font></div>
<div style="font-size:11px"><font face="Menlo">};</font></div>
<div style="font-size:11px"><font face="Menlo"><br>
</font></div>
<div style="font-size:11px"><font face="Menlo">__attribute__((address_space(N))
Foo f;</font></div>
<div style="font-size:11px"><font face="Menlo"><br>
</font></div>
<div style="font-size:11px"><font face="Menlo">void main()
{</font></div>
<div style="font-size:11px"><font face="Menlo"> f.bar();</font></div>
<div style="font-size:11px"><font face="Menlo">}</font></div>
<div><br>
</div>
<div>Results in the following error message:</div>
<div><br>
</div>
<div>
<div style="font-size:11px"><font face="Menlo">error:
cannot initialize object parameter of type 'const
Foo' with an expression of type
'__attribute__((address_space(200))) Foo'</font></div>
<div style="font-size:11px"><font face="Menlo">
f.bar(0);</font></div>
</div>
<div><br>
</div>
<div>It seems to me that const/non-const is orthogonal to
address space attributes, so if one method invocation
works, the other should as well. So my question is:
which behavior is intended to be correct? Should Clang
allow methods on arbitrary address spaces? (if not, how
would one write a method to be used on the address space
version?) It seems like this question must come up in
the OpenCL/CUDA extensions, but I am not familiar with
those so don’t know how this is handled there.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>-Brandon</div>
<div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div style="word-wrap:break-word">
<div>
<blockquote type="cite">
<div style="word-wrap:break-word">
<div><br>
<div>Begin forwarded message:</div>
<br class="x_Apple-interchange-newline">
<blockquote type="cite">
<div style="margin-top:0px; margin-right:0px;
margin-bottom:0px; margin-left:0px">
<span style="font-family:Helvetica"><b>From: </b></span><span
style="font-family:'Helvetica'">Matt Arsenault
<<a moz-do-not-send="true"
href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>><br>
</span></div>
<div style="margin-top:0px; margin-right:0px;
margin-bottom:0px; margin-left:0px">
<span style="font-family:Helvetica"><b>Subject: </b></span><span
style="font-family:'Helvetica'"><b>Re: [LLVMdev]
Methods on addrspace pointers</b><br>
</span></div>
<div style="margin-top:0px; margin-right:0px;
margin-bottom:0px; margin-left:0px">
<span style="font-family:Helvetica"><b>Date: </b></span><span
style="font-family:'Helvetica'">January 20, 2014
at 3:41:07 PM PST<br>
</span></div>
<div style="margin-top:0px; margin-right:0px;
margin-bottom:0px; margin-left:0px">
<span style="font-family:Helvetica"><b>To: </b></span><span
style="font-family:'Helvetica'">Hal Finkel <<a
moz-do-not-send="true"
href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>,
Brandon Holt <<a moz-do-not-send="true"
href="mailto:bholt@cs.washington.edu">bholt@cs.washington.edu</a>><br>
</span></div>
<div style="margin-top:0px; margin-right:0px;
margin-bottom:0px; margin-left:0px">
<span style="font-family:Helvetica"><b>Cc: </b></span><span
style="font-family:'Helvetica'">LLVM Developers
Mailing List <<a moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
</span></div>
<br>
<div>On 01/20/2014 03:29 PM, Hal Finkel wrote:<br>
<blockquote type="cite"><br>
2. Is there a way to create methods that can be
called with pointers<br>
to different address spaces? It seems there is no
way to declare<br>
these in C++ using GNU attributes, and addrspace()
seems to not be<br>
supported by C++11 attribute syntax, which could
possibly express<br>
this. You can use __attribute__((address_space(N))<br>
<br>
<br>
<br>
I have already been using that syntax to annotate
pointer<br>
declarations. However I don’t think it can be
applied to methods the<br>
way I was thinking. At least it doesn’t actually
change them:<br>
<br>
<br>
<br>
struct Foo {<br>
long x;<br>
<br>
__attribute__((address_space(7))) void bar(long y)
{<br>
printf("%ld %ld\n", x, y);<br>
}<br>
};<br>
<br>
<br>
Generates this declaration still:<br>
<br>
<br>
define linkonce_odr void
@_ZN3Foo3barEl(%struct.Foo* %this, i64 %y)<br>
ssp uwtable align 2<br>
<br>
<br>
Though I think desired behavior would be:<br>
<br>
<br>
define linkonce_odr void
@_ZN3Foo3barEl(%struct.Foo addrspace(7) *<br>
%this, i64 %y) ssp uwtable align 2<br>
<br>
<br>
(actually I think it’s more tricky because the
address_space<br>
attribute could be applying to the return type.
I’d think the<br>
correct way to specify the attribute on “this”
would be to put it<br>
where “const” goes, after the parentheses)<br>
Does it make sense for 'this' to be in one address
space on some functions and in a different address
space in other functions? If so, should the
address space of 'this' contribute to overload
resolution?<br>
<br>
-Hal<br>
</blockquote>
<br>
Yes it would. The struct itself has no specified
address space, but the instances of it would.<br>
<br>
__attribute__((address_space(1)) Foo f1;<br>
__attribute__((address_space(2)) Foo f2;<br>
<br>
f1.bar() and f2.bar() would need to call functions
with different address spaced this pointers. Support
for this would be required to support the OpenCL
static C++ extension<br>
<br>
<blockquote type="cite"><br>
<blockquote type="cite"><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>