[LLVMdev] Address space extension

[Justin Holewinski]

On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale <
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?


>
> -Michele
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130811/04b68d3b/attachment.html>