[LLVMdev] alias set collapse and LICM

Daniel Berlin dberlin at dberlin.org
Mon Apr 27 16:27:17 PDT 2015


On Mon, Apr 27, 2015 at 4:21 PM Daniel Berlin <dberlin at dberlin.org> wrote:

> You can't win here (believe me, i've tried, and better people than me have
> tried, for years :P).
> No matter what you do, the partitioning will never be 100% precise.  The
> only way to solve that in general is to pairwise query over the
> partitioning.
>
> Your basic problem is that all of the alias analyses do not come up with
> the same partitioning of the heap.
>
> Worse, some are not even transitive, or even symmetric.
>
> This means one single variable may be in multiple disjoint alias sets in
> reality.
>
> (For example, GEP, PHI will give you different AA results than PHI, GEP in
> some cases. That is mostly a FIXME, but there are plenty of cases you can
> come up with where info tells you something about one variable and it's
> relationship to another, but not to a third. The non-symmetric case is
> rarer, but again, possible.)
>
> Let's say you modify AliasSetTracker to not collapse, and handle multiple
> disjoint partitions at once.
>
> (Here is here i will draw the equivalence between this and what we've done
> before in GCC :) )
>
> The only way to maintain correctness (in general) and not collapse is to
> maintain multiple alias sets, and say which are affected by which
> instructions.
>
> (IE you have 1 instruction, and it may MOD 5 different alias sets, each of
> which represents a different partitioning of the heap).
>
> You will discover very quickly, that for most partitioning you can think
> of, the cost of maintaining the alias sets over a set of instructions with
> is greater than the cost of additional queries you may come up with in the
> first place
>
> In other words, depending on how precise your partitioning you may have
> variables that clobber 10 or 20 or 30 of the disjoint alias sets.
>

This should be "instructions", not variables.

>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150427/77f1d1d9/attachment.html>


More information about the llvm-dev mailing list