[llvm-dev] [RFC] BasicAA considers address spaces?

[Matt Arsenault via llvm-dev]

On 08/07/2015 11:35 AM, Jingyue Wu wrote:
> + the new llvm-dev
>
> On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <jingyue at google.com 
> <mailto:jingyue at google.com>> wrote:
>
>     Hi folks,
>
>     Unsurprisingly, leveraging the fact that certain address spaces
>     don't alias can significantly improve alias analysis precision and
>     enhance (observably 2x performance gain) load/store optimizations
>     such as LICM and DSE.
>
>     This sounds to me an overdue feature. I saw several discussion
>     threads on that direction, but none of them really happened.
>
>     (1)
>     http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129615.html.
>     Justin Holewinski proposed to add an address-space alias analysis
>     that treats pointers in different address spaces not aliasing.
>     This patch got shot down because, in some targets, address spaces
>     may alias. For example, in CUDA+NVPTX, addrspace(0) aliases everyone.
>
>     (2)
>     http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064620.html. Michele
>     Scandale proposed address space extensions in IR metadata which
>     TBAA could then leverage to prove non-aliasing. This approach
>     didn't fly either because address spaces are target-specific. The
>     front end doesn't know enough to decide aliasing.
>
>     So, can we make BasicAA to consider address spaces? Specifically,
>     I am proposing:
>     a) adding a new interface like TTI::addressSpacesAlias(unsigned,
>     unsigned), and
>     b) adding a little piece of logic in BasicAA that reports "no
>     alias" if address spaces don't alias.
>
>     This approach addresses the issue brought up in (2) because TTI
>     can see the entire codegen. It also resolves the issue that shut
>     down (1) because it allows address spaces to alias in a
>     target-defined way. Actually, John Criswell did mention in that
>     thread the idea of embedding alias info in TargetData. Now that we
>     have TTI, it seems a better place to hold target-specific alias
>     info than DataLayout.
>
>     Any comments?
>
>     Jingyue
>
>
We definitely need something to handle this.

I think a TTI::addressSpaceAlias is a good idea, although I don't think 
this fully solves the language vs. target address space distinction a 
metadata based approach was supposed to handle although it would be 
easier to implement. For our GPU purposes this would mostly be enough. 
For example, the fact that in OpenCL local vs. global pointers won't 
alias is a useful distinction, even though for a CPU target those will 
all be mapped to address space 0 so in some cases the frontend knows 
more about aliasing address spaces than the target.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150807/cd0e3f45/attachment.html>