[PATCH] D18798: New code hoisting pass based on GVN

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 8 22:36:12 PDT 2016


On Fri, Apr 8, 2016 at 3:03 PM, Sebastian Pop <sebpop at gmail.com> wrote:

> sebpop removed rL LLVM as the repository for this revision.
> sebpop updated this revision to Diff 53095.
> sebpop added a comment.
>
> In http://reviews.llvm.org/D18798#394160, @chandlerc wrote:
>
> > - We also would likely need to see a reasonable analysis of the effect
> this has on compile time so we understand the tradeoff this is making. My
> suspicion is that it won't be the correct tradeoff for O2 if it is correct
> at any level. (See below.) [...]  It makes very little sense IMO to do
> early-cse and then early-gvn... The only point of early-cse was to be a
> substantially lighter weight CSE than GVN. If you're going to run GVN
> anyways to do hoisting, just run GVN.
>
>
> I think there is a misconception of "GVN == PRE":


No, it's GVN == GVN + elimination in LLVM.

this is because GVN.cpp was
> around for a while and the "GVN pass" is a "redundancy elimination" pass.
>
> That is because it is in LLVM :)


> To clarify matters, GVN is an analysis pass,


In the theoretical sense, yes.
But, as you know, it's not, as currently implemented in LLVM.
Analysis passes do not modify code.
GVN modifies code.
As it runs, it deletes code, it simplifies instruction, etc.
What you are using is *not* GVN.
You have taken a very small part of GVN, and reused it.

In particular, you've taken the hash table.  But the hash table only barely
performs value numbering.

In fact, current GVN relies *very* heavily on it's current model of
simplification + elimination as it goes to perform *value numbering*.

What you are using will miss *very* obvious cases.
It's a very trivial value numberer.

(For example, without elimination-as-it-goes, given

c = a + 1
d = c + 1
e = a + 2

It will never discover e and c have the same value, etc)

This is going to severely limit your code hoisting opportunities.

This is precisely one of the reasons i've split it up into analysis and
elimination, while keeping enough power to discover the same set of value
numbers :)

(I know you know all this).

I don't think we are going to be able to take back the term "GVN" in LLVM
anytime soon, sadly.



like SCEV or data dependence are
> analysis passes. What GVN does is similar to what md5 does to a text file:
> given an instruction, GVN returns a unique integer identifying what the
> compiler
> safely estimates as identical computations.
>

This is a great statement of how the world *should* be, and what you know
i'm trying to achieve, but ... :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160408/f5df6be5/attachment.html>


More information about the llvm-commits mailing list