[PATCH] D115052: [Passes] Only run extra vector passes if loops have been vectorized.

[Florian Hahn via Phabricator via llvm-commits]

fhahn updated this revision to Diff 393130.
fhahn added a comment.

Updated to only invalidate the marker analysis when explicitly invalidated as suggested.

I also run a set of benchmarks including SPEC2006/Geekbench on AArch64 (extra vector passes enabled) with and without this patch and there were no notable performance differences.

In D115052#3176907 <https://reviews.llvm.org/D115052#3176907>, @xbolva00 wrote:

>>> It is probably still too high to enable by default, but much better.
>
> It depends, for -O3, this may not be an issue. Maybe worth to look at "mafft"? (+4.17%)

Possibly, but I rather not get into this discussion at least until the major compile-time issue this patch addresses has been fixed. I suspect there is potential to tune the 'extra' vector pass sequence a bit more, but unfortunately I won't be able to drive towards enabling by default in the near future.

In D115052#3181453 <https://reviews.llvm.org/D115052#3181453>, @aeubanks wrote:

> this is a little different from D113947 <https://reviews.llvm.org/D113947> in that we're using an analysis to keep track of something that must happen if a pass did something, whereas D113947 <https://reviews.llvm.org/D113947> uses an analysis to keep track of if we *don't* have to do something
> the only other thing I can think of that's somewhat similar is the devirtualization wrapper where we keep track of the number of direct/indirect calls, and also using value handles to keep track of if any devirtualization happened, and rerun passes if it did
>
> I guess there isn't a great alternative to something like this unless we have some sort of marker within the IR itself, which doesn't really make any sense
> so something along these lines seems fine to me

Yeah, at the moment I don't think there's a general alternative to optionally running passes and using a marker analysis seems like a very convenient way to use the new pass manager to do that.

A related issue was discussed a while ago on llvm-dev ('Execute intrinsic lowering passes on demand' thread) [1] . It might be possible to use a similar approach to conditionally execute various intrinsic lowering passes.

[1] https://lists.llvm.org/pipermail/llvm-dev/2020-March/140531.html


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115052/new/

https://reviews.llvm.org/D115052

Files:
  llvm/include/llvm/Transforms/Vectorize/LoopVectorize.h
  llvm/lib/Passes/PassBuilderPipelines.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/test/Other/opt-pipeline-vector-passes.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D115052.393130.patch
Type: text/x-patch
Size: 6566 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211209/667f5335/attachment.bin>