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

[Chandler Carruth]

On Sat, Sep 7, 2013 at 12:48 PM, 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.
>
> I think that this is not quite the right way to think about it, especially
> in the context of a nearly-complete rewrite.


The context I'm coming from is that of the current state of GVN. I don't
know anything really about Danny's prototype other than the fact that some
others looked at cleaning it up and making it work, and couldn't get it
cleaned up and working well enough to justify the cost of adding. Maybe
others will have better luck.


> First, we need to answer the question: Is this fundamentally something
> that we need GVN to do? If it is, then it should be evaluated as I said. If
> not, then we need to figure out where (if anywhere) is a better place.
>

Sure, but that's totally orthogonal.


> Ideally, we should really start to review Danny's GVN rewrite (even though
> it may, as he says, need a rewrite itself), so that we can at least all get
> on the same page regarding what the new version does, how it does it, and
> what functional improvements will be necessary prior to the start of
> more-extensive testing.
>

If you have time for this, cool. But that doesn't actually impact my stance
here in either direction, and should really be a separate discussion.


> Maintenance of the current GVN is obviously a concern, but if we block
> improvements to GVN now because GVN needs to be redone, we loose the
> ability of the current GVN to serve as the best possible reference
> implementation to which we should compare the new GVN. The lost
> productivity from failing to do that (failing to capture the work put into
> isolating performance problems, mitigating them, and building up the
> corresponding test cases, and then building on those improvements) is
> likely to be greater than the extra maintenance burden (IMHO).
>

I think you are continuing to misinterpret what I'm saying.

I do not want to block anything. I think that the current maintenance
challenges of GVN and the scope creep that has occurred in the set of
optimizations it performs will make the costs in your cost-benefit analysis
extremely high for changes which add new functionality to GVN. That doesn't
mean they couldn't be demonstrated as worth while as it remains a tradeoff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130907/5c1a8414/attachment.html>