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

Hal Finkel hfinkel at anl.gov
Tue Oct 14 12:24:26 PDT 2014

----- 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

More information about the llvm-dev mailing list