(original) (raw)
On 03/25/2014 05:07 PM, Jingyue Wu
wrote:
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.
On Tue, Mar 25, 2014 at 3:21 PM, Matt Arsenault <Matthew.Arsenault@amd.com> wrote:
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.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."
"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?
New hardware does have flat address space instructions, which is what my patch adds support for. They're just not defined in the target yet. This flat address space is separate different from 0 / the default. I think of addrspace(0) as the address space of allocas, so I don't understand how that can be consolidated with generic accesses of the other address spaces. Does NVPTX not differentiate between accesses of a generic pointer and private / alloca'd memory?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.
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.
I also do not understand how NVPTX uses address spaces, particularly how it can use 0 as the the generic address space.
NVPTX backend generates ld.f32 for reading from the generic address space. There's no special machine instruction to read/write from/to the generic address space in R600?
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),
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.
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.
We also think InstCombine is a good place to put this
optimization, if we decide to go with target-independent.
Looking forward to your patches!
I think that strategy only gets you part of the way to ideal. For
example, preferring to use the original address space works well for
accesses to objects where you start with the known address space.
You could also have a function with a generic address space argument
casted back to a specific address space. Preferring the original
address space in that case is the opposite of what you want,
although I expect this case will end up being much less common in
real code and will tend to go away after inlining.