[LLVMdev] Reducing Generic Address Space Usage

[Justin Holewinski]

On 03/25/2014 06:21 PM, Matt Arsenault wrote:
> On 03/25/2014 02:31 PM, Jingyue Wu wrote:
>>
>> However, we have three concerns on this:
>> a) I doubt this optimization is valid for all targets, because LLVM 
>> language reference 
>> (http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction) says 
>> addrspacecast "can be a no-op cast or a complex value modification, 
>> depending on the target and the address space pair."
> I think most of the simple cast optimizations would be acceptable. The 
> addrspacecasted pointer still needs to point to the same memory 
> location, so changing an access to use a different address space would 
> be OK. I think canonicalizing accesses to use the original address 
> space of a casted pointer when possible would make sense.
>
>> b) NVPTX and R600 have different address numbering for the generic 
>> address space, which makes things more complicated.
>> c) We don't have a good understanding of the R600 backend.
>>
>
> R600 currently does not support the flat address space instructions 
> intended to use for the generic address space. I posted a patch a 
> while ago that half added it, which I can try to work on finishing if 
> it would help.
>
> I also do not understand how NVPTX uses address spaces, particularly 
> how it can use 0 as the the generic address space.

We handle alloca by expanding it to a local stack reservation plus a 
pointer conversion to the generic address space.  So if we have IR like 
the following:

%ptr = alloca i32
store i32 0, i32* %ptr

This will really get expanded to something like the following at 
MachineInstr-level (in pseudo-code):

%local_ptr = %SP+offset    ; Stack pointer (in thread-local [private] 
address space)
%ptr = convert %local_ptr to generic address
store.generic.i32 [%ptr], 0

With the proposed optimization, this would be optimized back to a 
non-generic store:

%local_ptr = %SP+offset
%ptr = convert %local_ptr to generic address
%ptr.0 = convert %ptr to thread-local address space
store.local.i32 [%ptr.0], 0

This turns the address space conversion sequence into a no-op (assuming 
no other users) that can be eliminated, and a non-generic store is 
likely to be more efficient than a generic store.

>
>> 2. How effective do we want this optimization to be?
>>
>> In the short term, I want it to be able to eliminate unnecessary 
>> non-generic-to-generic addrspacecasts the front-end generates for the 
>> NVPTX target. For example,
>>
>> %p1 = addrspace i32 addrspace(3)* %p0 to i32*
>> %v = load i32* %p1
>>
>> =>
>>
>> %v = load i32 addrspace(3)* %p0
>>
>> We want similar optimization for store+addrspacecast and 
>> gep+addrspacecast as well.
>>
>> In a long term, we could for sure improve this optimization to handle 
>> more instructions and more patterns.
>>
> I believe most of the cast simplifications that apply to bitcasts of 
> pointers also apply to addrspacecast. I have some patches waiting that 
> extend some of the more basic ones to understand addrspacecast (e.g. 
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140120/202296.html), 
> plus a few more that I haven't posted yet. Mostly they are little cast 
> simplifications like your example in instcombine, but also SROA to 
> eliminate allocas that are addrspacecasted.
>
> -Matt


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140326/73a51945/attachment.html>