[LLVMdev] RFC: Should we have (something like) -extra-vectorizer-passes in -O2?

[Hal Finkel]

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: "James Molloy" <james at jamesmolloy.co.uk>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, October 14, 2014 1:21:21 PM
> Subject: Re: [LLVMdev] RFC: Should we have (something like) -extra-vectorizer-passes in -O2?
> 
> 
> I’ll summarize your responses as: The new pipeline produces better
> results than the old, and we currently have no good mechanism for
> reducing the compile time overhead.
> 
> 
> I’ll summarize my criticism as: In principle, there are better ways
> to clean up after the vectorizer without turning it into a
> complicated megapass, but no one has done the engineering. I don’t
> think cleaning up after the vectorizer should incur any noticeable
> overhead if the vectorizer never runs, and it would be avoidable
> with a sensibly designed passes that aren’t locked into the current
> pass manager design.
> 
> I don’t have the data right now to argue against enabling the new
> pipeline under O2. Hopefully others who care about clang compile
> time will jump in.
> 
> As for the long-term plan to improve compile-time, all I can do now
> is to advocate for a better approach.

Sure, but we should also have a plan ;) -- I think this is important, and we should make sure this doesn't get dropped. I don't think that the vectorizers are the only thing for which the concept of 'cleanup' passes are relevant. The critical piece here is that, if we don't need to run a cleanup pass, we also don't need to compute any analysis passes on which the pass might depend.

While I'm in favor of the new passes, I also want us to have a plan in this area. I understand that the pass manager is being rewritten, and maybe putting effort into the old one is not worthwhile now, but the new one should certainly have a design compatible with this requirement. Chandler?

 -Hal

> 
> 
> -Andy
> 
> 
> 
> 
> 
> On Oct 14, 2014, at 10:56 AM, Chandler Carruth < chandlerc at google.com
> > wrote:
> 
> 
> 
> 
> 
> On Tue, Oct 14, 2014 at 10:11 AM, Andrew Trick < atrick at apple.com >
> wrote:
> 
> 
> 
> >> + correlated-propagation
> 
> A little worried about this.
> 
> >> + instcombine
> 
> I'm *very* concerned about rerunning instcombine, but understand it
> may help cleanup the vectorized preheader.
> 
> 
> 
> Why are you concerned? Is instcombine that slow? I usually don't see
> huge overhead from re-running it on nearly-canonical code. (Oh, I
> see you just replied to Hal here, fair enough.
> 
> 
> 
> 
> >> + licm
> >> + loop-unswitch
> 
> These should limited to the relevant loop nest.
> 
> 
> 
> We have no way to do that currently. Do you think they will in
> practice be too slow? If so, why? I would naively expect unswitch to
> be essentially free unless it can do something, and LICM not much
> more expensive.
> 
> 
> 
> 
> >> + simplifycfg
> 
> OK if the CFG actually changed.
> 
> 
> 
> Again, we have no mechanism to gate this. Frustratingly, the only
> thing I want here is to delete dead code formed by earlier passes.
> We just don't have anything cheaper (and I don't have any
> measurements indicating we need something cheaper).
> 
> 
> 
> 
> >> + instcombine
> 
> instcombine again! This can’t be good.
> 
> 
> 
> I actually have no specific reason to think we need this other than
> the fact that we run instcombine after simplifycfg in a bunch of
> other places. If you're looking for one to rip out, this would be
> the first one I would rip out because I'm doubtful of its value.
> 
> 
> 
> On a separate note:
> 
> 
> 
> 
> 
> >> + early-cse
> 
> Passes like loop-vectorize should be able to do their own CSE without
> much engineering effort.
> 
> >> slp-vectorize
> >> + early-cse
> 
> SLP should do its own CSE.
> 
> I actually agree with you in principle, but I would rather run the
> pass now (and avoid hacks downstream to essentially do CSE in the
> backend) than hold up progress on the hope of advanced on-demand CSE
> layers being added to the vectorizers. I don't know of anyone
> actually working on that, and so I'm somewhat concerned it will
> never materialize.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory