[PATCH] Select Elimination in InstCombine

[Gerolf Hoflehner]

I was thinking about this a bit. The usual testing (llvm, some benchmarks) did not reveal a problem we are not aware of already, but it  sometimes is the case that you just measure what you want to measure. So deep down this is not really satisfying.

Are you aware of a stress test for CFG, ideally large CFG for an irreducible graph? For reducible graphs dominator calc is linear, so the only performance issue could  be memory, which any large graph should expose.

How useful is it to measure compile-time on a single pass? How much increase would we tolerate? Do you have any experience and data in that direction? That might be another angle to better address compile-time concerns. 

Probably a topic we should discuss in more depth at the conference.

Cheers
Gerolf



On Sep 10, 2014, at 5:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote:

> 
> On Wed, Sep 10, 2014 at 5:00 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
> Perhaps I should phrase it differently. DT is an analysis required by other passes like LICM which runs after the combiner.  The combiner does not destroy the Dominator Tree. So what is the root of your concern?
> 
> Requiring DT will likely cause DT to be run more times during the compilation (I'm pretty sure there is at least one place where nothing else needs it and there is a pass that invalidates it). As a consequence, this could *in theory* have an impact on compile time.
> 
> However, I don't actually expect it to have such an impact. I just think its reasonable to measure the compile time impact because sometimes my expectations are quite wrong. =]
> 
> (The only reason I mention a separate thread is to try to help make the code review progress faster -- the code is fine regardless of what the compile time results show, and we could potentially look at ways to get DT some of the time when it will be used later anyways but not always to avoid any compile time regressions.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140912/c9c0e9a0/attachment.html>