maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Other/opt-pipeline-vector-passes.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

53 lines
2.2 KiB
LLVM
Raw Normal View History

[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; RUN: opt -O1 -debug-pass=Structure < %s -o /dev/null 2>&1 | FileCheck %s --check-prefixes=OLDPM_O1
; RUN: opt -O2 -debug-pass=Structure < %s -o /dev/null 2>&1 | FileCheck %s --check-prefixes=OLDPM_O2
; RUN: opt -O1 -vectorize-loops=0 -debug-pass=Structure < %s -o /dev/null 2>&1 | FileCheck %s --check-prefixes=OLDPM_O1_FORCE_OFF
; RUN: opt -O2 -vectorize-loops=0 -debug-pass=Structure < %s -o /dev/null 2>&1 | FileCheck %s --check-prefixes=OLDPM_O2_FORCE_OFF
; RUN: opt -disable-verify -debug-pass-manager -passes='default<O1>' -S %s 2>&1 | FileCheck %s --check-prefixes=NEWPM_O1
; RUN: opt -disable-verify -debug-pass-manager -passes='default<O2>' -S %s 2>&1 | FileCheck %s --check-prefixes=NEWPM_O2
; REQUIRES: asserts
; SLP does not run at -O1. Loop vectorization runs, but it only
; works on loops explicitly annotated with pragmas.
; OLDPM_O1-LABEL: Pass Arguments:
; OLDPM_O1: Loop Vectorization
; OLDPM_O1-NOT: SLP Vectorizer
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; OLDPM_O1: Optimize scalar/vector ops
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; Everything runs at -O2.
; OLDPM_O2-LABEL: Pass Arguments:
; OLDPM_O2: Loop Vectorization
; OLDPM_O2: SLP Vectorizer
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; OLDPM_O2: Optimize scalar/vector ops
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; The loop vectorizer still runs at both -O1/-O2 even with the
; debug flag, but it only works on loops explicitly annotated
; with pragmas.
; OLDPM_O1_FORCE_OFF-LABEL: Pass Arguments:
; OLDPM_O1_FORCE_OFF: Loop Vectorization
; OLDPM_O1_FORCE_OFF-NOT: SLP Vectorizer
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; OLDPM_O1_FORCE_OFF: Optimize scalar/vector ops
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; OLDPM_O2_FORCE_OFF-LABEL: Pass Arguments:
; OLDPM_O2_FORCE_OFF: Loop Vectorization
; OLDPM_O2_FORCE_OFF: SLP Vectorizer
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; OLDPM_O2_FORCE_OFF: Optimize scalar/vector ops
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; There should be no difference with the new pass manager.
; This is tested more thoroughly in other test files.
; NEWPM_O1-LABEL: Running pass: LoopVectorizePass
; NEWPM_O1-NOT: Running pass: SLPVectorizerPass
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; NEWPM_O1: Running pass: VectorCombinePass
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
; NEWPM_O2-LABEL: Running pass: LoopVectorizePass
; NEWPM_O2: Running pass: SLPVectorizerPass
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; NEWPM_O2: Running pass: VectorCombinePass
[PassManager] add tests for vector pass enabling; NFC
2020-02-29 06:49:22 +08:00
define void @f() {
ret void
}