[cfe-dev] [LLVMdev] Methods on addrspace pointers

Tue Jan 28 11:21:02 PST 2014

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).

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...

On Jan 25, 2014, at 2:55 PM, Brandon Holt <bholt at cs.washington.edu> wrote:

> Bringing this to the attention of the Clang list because that’s actually where my problems exist.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> struct Foo {
>   void bar() const { /* … */ }
> };
> 
> __attribute__((address_space(N)) Foo f;
> 
> void main() {
>   f.bar();
> }
> 
> Results in the following error message:
> 
> error: cannot initialize object parameter of type 'const Foo' with an expression of type '__attribute__((address_space(200))) Foo'
>     f.bar(0);
> 
> 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.
> 
> Thanks,
> -Brandon
> 
> 
> 
> Begin forwarded message:
> 
>> From: Matt Arsenault <Matthew.Arsenault at amd.com>
>> Subject: Re: [LLVMdev] Methods on addrspace pointers
>> Date: January 20, 2014 at 3:41:07 PM PST
>> To: Hal Finkel <hfinkel at anl.gov>, Brandon Holt <bholt at cs.washington.edu>
>> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>> 
>> On 01/20/2014 03:29 PM, Hal Finkel wrote:
>>> 
>>> 2. Is there a way to create methods that can be called with pointers
>>> to different address spaces? It seems there is no way to declare
>>> these in C++ using GNU attributes, and addrspace() seems to not be
>>> supported by C++11 attribute syntax, which could possibly express
>>> this. You can use __attribute__((address_space(N))
>>> 
>>> 
>>> 
>>> I have already been using that syntax to annotate pointer
>>> declarations. However I don’t think it can be applied to methods the
>>> way I was thinking. At least it doesn’t actually change them:
>>> 
>>> 
>>> 
>>> struct Foo {
>>> long x;
>>> 
>>> __attribute__((address_space(7))) void bar(long y) {
>>> printf("%ld %ld\n", x, y);
>>> }
>>> };
>>> 
>>> 
>>> Generates this declaration still:
>>> 
>>> 
>>> define linkonce_odr void @_ZN3Foo3barEl(%struct.Foo* %this, i64 %y)
>>> ssp uwtable align 2
>>> 
>>> 
>>> Though I think desired behavior would be:
>>> 
>>> 
>>> define linkonce_odr void @_ZN3Foo3barEl(%struct.Foo addrspace(7) *
>>> %this, i64 %y) ssp uwtable align 2
>>> 
>>> 
>>> (actually I think it’s more tricky because the address_space
>>> attribute could be applying to the return type. I’d think the
>>> correct way to specify the attribute on “this” would be to put it
>>> where “const” goes, after the parentheses)
>>> 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?
>>> 
>>>  -Hal
>> 
>> Yes it would. The struct itself has no specified address space, but the instances of it would.
>> 
>> __attribute__((address_space(1)) Foo f1;
>> __attribute__((address_space(2)) Foo f2;
>> 
>> 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
>> 
>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/b469a5bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implicit_addrspacecast.diff
Type: application/octet-stream
Size: 1127 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/b469a5bb/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/b469a5bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_addrspace_call.diff
Type: application/octet-stream
Size: 1267 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/b469a5bb/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/b469a5bb/attachment-0002.html>