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

[Jingyue Wu via llvm-dev]

On Fri, Aug 7, 2015 at 12:01 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> 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> 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
>

Thanks for pointing this out, Matt. In that case, I'd suggest LLVM have
both TTI- and metadata-based approaches, the former for targets being more
knowledgeable, and the latter for front-ends being more knowledgeable. They
are quite orthogonal.


> 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/1065bc3e/attachment-0001.html>