[llvm-commits] [Review request] Have Correlated Value Propagation handle instruction operands.

Frits van Bommel fvbommel at gmail.com
Tue Feb 8 10:14:53 PST 2011


On Tue, Feb 8, 2011 at 5:46 PM, Duncan Sands <baldrick at free.fr> wrote:
>>> Do you done any measurements of the compile-time impact of this?
>> No, sorry. Duncan Sands was worried about this too...
>
> it is very expensive.  I ran some comparisons and it is very visible that
> with
> your patch compilation is much slower.

:(

> The obvious thing to do is to keep your
> logic but only analyse a small set of instructions, for example the ones it
> used
> to analyse (Select, PHI, I/FCmp, Load, Store) plus branch instructions.
>  Sadly
> the result is disappointing: it catches way less stuff than my pass.  I then
> tried with your original patch, i.e. analysing all instructions.  It still
> catches way less stuff than my pass if I judge by the number of lines of
> bitcode
> removed.  I don't understand this since indeed LVI knows lots of tricks, so
> it
> is probably worth trying to understand why correlated value propagation/LVI
> is
> not doing a better job.
>
> PS: Way less = order of magnitude.

One obvious thing to check for is whether the ability of your pass to
use e.g. X == Y even if neither is constant is a factor. LVI only
returns constants; what happens if your pass refuses to substitute
non-constants? Is the loss of effectiveness comparable?

I also noticed that LVI nor correlated value propagation requires
dominator info. Is this because LVI effectively calculates this
itself? If not, could this perhaps cause CVP+LVI to be overly
pessimistic if a condition is reused in a block that is only dominated
by the outgoing edge? (instead of directly in the block the outgoing
edge jumps to)

(Note that I only have a vague idea of how LVI works internally)




More information about the llvm-commits mailing list