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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 7 11:56:53 PDT 2015

+1 to the general idea of a target dependent hook for describing 
aliasing of address spaces.  I have no opinion on the particular 
implementation strategy proposed.

On 08/07/2015 11:35 AM, Jingyue Wu via llvm-dev 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

More information about the llvm-dev mailing list