[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