On 08/11/2013 10:38 PM, Justin Holewinski wrote:> On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale <michele.scandale at
gmail.com
> <mailto:michele.scandale at gmail.com>> wrote:
>
> On 08/11/2013 08:41 AM, Micah Villmow wrote:
> > How about this as a solution.
> >
> > Add one hook into TargetInstrInfo, and one into
TargetISelLowering.
> >
> > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns
either
> disjoint, subset, superset, equal. Function defaults to equal.
> > 2) isAddressSpaceSupported(unsigned AS) - Returns true if
supported, false
> otherwise. Function defaults to false for all non-zero AS.
> >
> > These could be used by IR passes to optimized(#1) and
legalization(#2). It
> requires no changes by backends that do not want to support multiple
address
> spaces and extremely minimal and reasonable support by backends that
do. On
> a plus side, it also requires no IR/Module changes.
>
> To know if two address spaces are disjoint for alias analysis purpose,
it's more
> effective to know if in the source language the property holds or not,
because
> as said two disjoint address spaces in the abstract model (like the one
defined
> by OpenCL) can be implemented in the same physical address space in
separated
> regions, so asking to the target wont produce the correct answer for
all the
> targets (see X86 or whatever 'classical' processor with one
address space)!
>
>
> Which is why I believe metadata is the right approach here. The physical
> address space mapping can be left as a part of the IR as it is now; the IR
is
> target-dependent anyway and the metadata should not be needed for
correctness.
> Then you can attach metadata to the IR that assigns language-specific
semantics
> to the IR. If the metadata doesn't exist, or is stripped out, the
optimizers
> have to assume aliasing. This metadata doesn't need to be
language-specific.
> As mentioned earlier in the thread, it can just be mapping that assigns a
> logical address space to loads/stores, and defines which address spaces
overlap.
> Maybe to avoid confusion, instead of calling them address spaces, we could
call
> them address regions or something like that. Just so they're not
confused with
> LLVM IR address spaces.
>
> This combined with Micah's proposal for the two new hooks should handle
all of
> the use-cases. An optimizer can first look at the physical address spaces.
If
> they are different and the target states that they do not alias, then they
do
> not alias. This would handle aliasing for the case of generic IR. But if
they
> may alias due to the address space information (e.g. always for X86), then
the
> optimizer can look for metadata created by the front-end (e.g. clang
OpenCL) and
> use that to see if aliasing is possible. In the case of OpenCL, the
metadata
> would say aliasing is not possible between private and local memory. So
even if
> the LLVM IR address spaces are the same, the optimizer will know that
aliasing
> is not possible.
>
> Any I missing something here?
Now it's clear and I'm confident it will be fine. So the addrspace
modifier
semantic will be the current one (so target address spaces).
The idea is to extend the BasicAliasAnalysis to use addrspace modifier + target
information to decide aliasing based on physical address spaces and create a
"MemorySpaceAliasAnalysis" for those case where source language level
information may help, right?
Thanks.
-Michele