[LLVMdev] Reducing Generic Address Space Usage

Philip Reames listmail at philipreames.com
Wed Mar 26 14:16:03 PDT 2014


On 03/25/2014 05:32 PM, Matt Arsenault wrote:
> On 03/25/2014 05:07 PM, Jingyue Wu wrote:
>>
>>
>>
>> On Tue, Mar 25, 2014 at 3:21 PM, Matt Arsenault 
>> <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> 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.
>>
>>
>> "the address space conversion is legal then both result and operand 
>> refer to the same memory location". I don't quite understand this 
>> sentence. Does the same memory location mean the same numeric value?
> No, it means they could both have different values that point to the 
> same physical location. Storing to a pointer in one address space 
> should have the same effect as storing to the addrspacecasted pointer, 
> though it might not use the same value or instructions to do so.
This interpretation fits my reasoning as well.

I would assume it's legal to reason about aliasing (for value 
forwarding, etc..), but not to reason about the semantics of the exact 
load used.  (i.e. one could perform a runtime manipulation of the loaded 
value, the other might not)

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140326/8a33832d/attachment.html>


More information about the llvm-dev mailing list