E-SSA and Predicate Info (was RE: [PATCH] D28459: Make processing @llvm.assume more efficient - Add affected values to the assumption cache)

[Daniel Berlin via llvm-commits]

In any case, if you want to play with it, it's here:
https://github.com/dberlin/llvm-gvn-rewrite/tree/newgvn-predicateinfo

-print-predicateinfo -analyze will give you info.

-newgvn will process simple equality and inequality right now using that
info[1]

This  is pretty much as cheap as you can make it.
We compute it in O(number of uses of comparison operations that are used in
terminators) worst case time.
So it's not even O(number of instructions) unless your program is only
comparisons and branches :P

This includes pruning - it will not insert predicate info copies except
where they are actually used on a branch.

(the same O(uses) algorithm works for general SSA renaming as well)

Adding assume support would just require coming up with a copy operation,
and doing local numbering in the assume blocks only (so we get def vs use
order right in that block).

[1]  There's a little work to be done, but it's actually very easy at this
point to catch 95% of the cases GVN does.  It has some ridiculous cases
that we would have to insert more predicate info to catch, like this;

%tmp1 = load @a
%tmp2 = icmp eq %tmp1, 0
branch to bb1 if true

bb1:
%tmp3 = load @a
%tmp4 = icmp eq %tmp3, 4

If you run early-cse or newgvn first, so the loads get eliminated, it will
get it. If this case occurs enough in practice, we can also just insert
predicateinfo during analysis.


On Tue, Jan 10, 2017 at 6:56 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 01/10/2017 08:51 PM, Daniel Berlin wrote:
>
> I think this is fine, because you want it in 4.0.
>
> We can build the infrastructure for the next thing pretty quickly, and if
> that means this lives a few months, so be it.
>
> I have a working version of e-ssa at this point with no ir changes that
> i'm testing (it uses one argument phi nodes like lcssa, and a side lookup
> table).
>
>
> Sounds good, thanks! We'll just need to work out exactly how this will
> work with assumes, guards, etc. and how far you want to take it (e.g. at
> some limit, this becomes SSI).
>
>  -Hal
>
>
>
> On Tue, Jan 10, 2017 at 6:39 PM, Hal Finkel via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> hfinkel added a comment.
>>
>> In https://reviews.llvm.org/D28459#642239, @davide wrote:
>>
>> > In https://reviews.llvm.org/D28459#642235, @davide wrote:
>> >
>> > > Sorry for the delay, Hal.
>> > >  I just checked and this doesn't regress the cases your previous
>> change regressed, so we should be good on that side.
>> > >  I somehow share Dan's feeling that this could be solved with an
>> infrastructural changes rather than caching, but I don't feel to be in a
>> position to hinder progress without a concrete/implemented alternative.
>> >
>> >
>> > For those wondering, I mean http://lists.llvm.org/pipermai
>> l/llvm-commits/Week-of-Mon-20170102/416193.html
>>
>>
>> @dberlin , @chandlerc , et al. does anyone object to me committing this
>> solution at this point? I'm obviously happy to help replace it later with
>> something based on an extended SSA form once we figure out how that should
>> work. In the mean time, this fixes the compile-time problems, which users
>> are certainly hitting, in a fairly transparent way.
>>
>>
>> https://reviews.llvm.org/D28459
>>
>>
>>
>>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170114/77a02955/attachment.html>