[Patch] GVN fold conditional-branch on-the-fly

Chandler Carruth chandlerc at google.com
Sat Sep 7 12:16:05 PDT 2013


On Sat, Sep 7, 2013 at 11:48 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> I think that we should evaluate this change just like any other: using a
> cost-benefit analysis of performance vs. compile-time impact averaged over
> the test suite (and any other code bases we care about). As a practical
> matter, we should not hold all GVN-related improvements hostage to
> competition of a GVN rewrite on which no one is actively working.


I don't think Danny was suggesting this.

There is a difference between holding all improvements hostage, and arguing
against growing the complexity of a pass which is in serious need of
refactoring/updating until that occurs. Especially when the reworking
proposed is likely to achieve the same concrete goal is the added
complexity.

I do think that GVN has likely reached the point where adding new layers of
complexity to it significantly grow both the cost of maintenance of GVN and
the cost of doing a deep reworking of it. I've watched folks try to do deep
improvements to our GVN infrastructure, and they have to spend more time
trying to replicate all of the current tweaks, hacks, and complexity in it
than they do improving the fundamentals of the pass.

That doesn't mean we can't possibly improve it as is, but I think there
should be a *really* significant need in the immediate future, and some
plan or path toward a principled and more maintainable solution. It
essentially places a very large scaling factor on the cost side of the
cost-benefit analysis because we need to prioritize the long-term needs of
the project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130907/dfc1f9b2/attachment.html>


More information about the llvm-commits mailing list