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

[Hal Finkel via llvm-commits]

On 01/14/2017 05:21 PM, Daniel Berlin wrote:
>
> 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).

Looks good, thanks! The code you have in 
PredicateInfo::buildPredicateInfo looks essentially like the code I have 
in AssumptionCache::updateAffectedValues; we just need to update the 
PredicateInfo version to catch a few more cases that the assumptions need.

I don't understand what you mean by "in the assume blocks only." I'd 
think we'd need to treat these just like dominating conditional-branch 
conditions, so we'd need to rename all uses dominated by the assumption 
in all blocks.

Thanks again,
Hal

>
> [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 
> <mailto: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 <mailto:reviews at reviews.llvm.org>> wrote:
>>
>>         hfinkel added a comment.
>>
>>         In https://reviews.llvm.org/D28459#642239
>>         <https://reviews.llvm.org/D28459#642239>, @davide wrote:
>>
>>         > In https://reviews.llvm.org/D28459#642235
>>         <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/pipermail/llvm-commits/Week-of-Mon-20170102/416193.html
>>         <http://lists.llvm.org/pipermail/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 <https://reviews.llvm.org/D28459>
>>
>>
>>
>>
>
>     -- 
>     Hal Finkel
>     Lead, Compiler Technology and Programming Languages
>     Leadership Computing Facility
>     Argonne National Laboratory
>
>

-- 
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/10f5b9ab/attachment.html>