[llvm-commits] [patch] Use the new edge dominance functions in GVN

Daniel Berlin dannyb at google.com
Thu Aug 16 09:01:18 PDT 2012


On Thu, Aug 16, 2012 at 11:57 AM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
>> Performance experience.
>> My recollection is it starts to fall down very quickly on code
>> generated code that has a lot of switch statement
>> fallthroughs/critical edges.  I should hopefully still be able to find
>> them (I believe the worst were from some scheme-to-c compiler)
>>
>> This often causes PRE that edge-splits on demand to iterate.
>> Iteration in PRE, copying sets around, and recalculation of other
>> stuff, always took more time than pre-splitting edges.
>
> ....
>
>> Sure. The current implementation does a fairly local form of PRE, and
>> isn't going to find that many opportunities right now anyway.
>> I can come up with a real  testcase where it's the most expensive, if
>> you like :)
>
> I see. So your thinking is that an algorithm that finds more PRE cases
> to explore would spend more time iterating and would benefit from
> upfront splitting. If you can build a testcase where that happens with
> the current implementation that would be awesome!

Without thinking too hard, you actually should be able to build one
using switch statements and fallthroughs, where the fallthroughs
operands depend on values set in the fallthrough before them.
(or something similar)

This way, it starts at the bottom and slowly iterates splitting each
critical edge in the switch fallthrough, finding a new PRE candidate
each time as it slowly is able to eliminate the now partially
redundant operands.

The GVN-PRE paper also has some examples where PRE candidates expose
other PRE candidates on the next iteration (IIRC), and so, should be
usable as a starting point to build bad cases for the current one.

--Dan




More information about the llvm-commits mailing list