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

[Jingyue Wu via llvm-dev]

+ the new llvm-dev

On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150807/fe2cc2cf/attachment.html>