[PATCH] [GVN] Eliminate redundant loads whose addresses are dependent on the result of a select instruction.

[Daniel Berlin]

So, this is an awfully specific redundancy to detect in GVN.

The more general case doesn't use select's but phi's, and is tested in gcc
with GVNPRE with testcases like:


 int
 foo (int i)
 {
     int a, b;
     if (i)
         a = 3, b = 2;
     else
         a = 2, b = 3;
     return a + b;
 }

and more complex testcase that involve expressions.
But the basic idea is the same - if both values are computed already, the
end is redundant.
(here, the result is constant along both edges)

GVN doesn't touch this (and wouldn't with your patch):

 ; Function Attrs: nounwind readnone ssp uwtable
 define i32 @foo(i32 %i) #0 {
   %1 = icmp eq i32 %i, 0
   %. = select i1 %1, i32 2, i32 3
   %.1 = select i1 %1, i32 3, i32 2
   %2 = add nsw i32 %., %.1
   ret i32 %2
 }


GCC treats this as a GVNPRE problem rather than a GVN one, because it
involves computing available values along edges.

Putting these as selects, sadly, makes it harder for things like PRE to see
this (though you could treat the selects are false blocks with incoming
edges)
It would compute the values are available along each edge already, and
insert a no-cost phi to merge them.


In any case, if we want it, sure.  I have no objections as even in GVN,
this is trivial to add to new gvn, it just costs time as a special case
until i rewrite PRE based on GVN.


On Thu, Mar 12, 2015 at 12:34 PM, Chad Rosier <mcrosier at codeaurora.org>
wrote:

> Revised patch with the following changes:
> -Reworked the code so that we now use def-use and use-def, rather than
> iterate over all instructions in the block.
> -Store can now feed the select.  I.e.,
>
>   a = (load (gep ptr_a 0 0))
>   store b (gep ptr_b 0 0))
>   c = (load (gep (select (cond, ptr_a, ptr_b)) 0 0))
>   -->
>   a = (load (gep ptr_a, 0, 0))
>   store b (gep ptr_b 0 0))
>   c = (select (cond, a, b))
>
> There were no correctness or performance regressions across spec2000,
> spec2006, and eembc on an A57 device.  The only benchmarks that hit this
> transform are spec2000/gcc, spec2000/vpr, and spec2006/dealII.  I saw a ~1%
> improvement in vpr, but that's basically noise. :o/
>
> Also, adding Daniel B. to the reviews as he seems to be working in this
> area as of late.
>
> All, please have a look.
>
> Chad
>
>
> http://reviews.llvm.org/D8120
>
> Files:
>   lib/Transforms/Scalar/GVN.cpp
>   test/Transforms/GVN/load-gep-select.ll
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150324/db57288c/attachment.html>