[LLVMdev] question about enabling cfl-aa and collecting a57 numbers

Daniel Berlin dberlin at dberlin.org
Thu Jan 15 15:05:27 PST 2015


On Thu, Jan 15, 2015 at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 15 January 2015 at 13:10, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> Yes.
>> I've attached an updated patch that does the following:
>>
>> 1. Fixes the partialalias of globals/arguments
>> 2. Enables partialalias for cases where nothing has been unified to a
>> global/argument
>> 3. Fixes that select was unifying the condition to the other pieces (the
>> condition does not need to be processed :P). This was causing unnecessary
>> aliasing.
>>
>
> Consider this:
>
> void *p = ...;
> uintptr_t i = p;
> uintptr_t j = 0;
> for (int a = 0; a < sizeof(uintptr_t); ++a) {
>   j = i >> (sizeof(uintptr_t) - a - 1) ? 1 : 0;
>   j <<= 1;
> }
> void *q = j;
>
> alias(p, q) isn't NoAlias. (Okay, it kinda is in C++, but not in the
> equivalent LLVM IR. Please don't make me rewrite my example in LLVM IR.)
>
> Agreed :)

But after chatting with you, i think we both agree that this change does
not affect.
I probably should not have said "the condition does not need to be
processed".  It would be more accurate to say "the reference to a condition
in a select instruction, by itself, does not cause aliasing"

What happens now is:

given %4 = select %1, %2, %3

we do
aliasset(%4) += %1
aliasset(%4) += %2
aliasset(%4) += %3

The first one is unnecessary.
There can be no alias caused simply because it is referenced in condition
of the select.

> We still need to process what %1 refers to (and we do).


To make this empirical, in your example, we get the right answer in CFL-AA.

Interestingly, i'll point out that basic-aa says:
  NoAlias: i8* %p, i8** %q
  NoAlias: i8** %p.addr, i8** %q

(I translated your case as best i can :P)

So you may want to implement it for real if you think it's supposed to be
handled right in basic-aa, because I don't believe it is :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150115/1b1eacb5/attachment.html>


More information about the llvm-dev mailing list