[llvm-commits] [PATCH] Address Space Alias Analysis

Justin Holewinski justin.holewinski at gmail.com
Wed Oct 12 13:11:31 PDT 2011


On Wed, Oct 12, 2011 at 2:52 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote:

>  ** **
>
> ** **
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Justin Holewinski
> *Sent:* Tuesday, October 11, 2011 7:55 PM
> *To:* Sandeep Patel
> *Cc:* llvm-commits
> *Subject:* Re: [llvm-commits] [PATCH] Address Space Alias Analysis****
>
> ** **
>
> On Tue, Oct 11, 2011 at 6:34 PM, Sandeep Patel <deeppatel1987 at gmail.com>
> wrote:****
>
> It seems like we could turn this on automatically if we ever see a use
> of a non-default address space.****
>
> ** **
>
> I hesitate to do this since some back-ends may not have the property that
> separate address spaces are entirely disjoint and cannot alias.  For PTX, we
> currently have this property because we use address spaces as a way to
> differentiate the different types of device memory.****
>
> *[Villmow, Micah] What about adding a backend hook to see if the address
> spaces are disjoint. In the PTX backend and our AMDIL backend, this could
> default to true for everything.  For other back ends, it could be a case by
> case basis. This might lower when the pass can be run, but would help with
> this issue.*
>

Unfortunately, this pass should be pushed up as high as possible to get the
most benefit.  When the default pass list is created, the target triple
could be considered, but this seems to unnecessarily introduce
target-dependent code in higher-level LLVM core.

Any opinions from the core developers?  It would be possible to add this
pass to the default alias analysis passes for some target triples.


> ****
>
>  ****
>
>
> deep****
>
>
> On Tue, Oct 11, 2011 at 3:08 PM, Justin Holewinski
> <justin.holewinski at gmail.com> wrote:
> > The attached patch provides a new alias analysis: Address Space Alias
> > Analysis.  This pass is off-by-default and has no impact on generated
> code
> > unless -asaa is provided to opt.
> > This analysis signals NoAlias for pointers in different address spaces.
>  The
> > primary target for this pass is GPU back-ends which use LLVM address
> spaces
> > as a means for differentiating memory types (on-chip shared, off-chip
> > global, etc.) and hence pointers in different address spaces cannot
> alias.
> >  For OpenCL code compiled with the PTX back-end, this improves
> performance
> > by over 2x in some of my test kernels due to LLVM using this alias
> > information to remove redundant loads.
> > Is this okay to commit?
> >
> > --
> >
> > Thanks,
> > Justin Holewinski
> >****
>
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Thanks,****
>
> ** **
>
> Justin Holewinski****
>
> ** **
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111012/03e900ba/attachment.html>


More information about the llvm-commits mailing list