[LV][REVEC][AArch64] Proof of concept for re-vectorisation#208213
Draft
gbossu wants to merge 1 commit into
Draft
[LV][REVEC][AArch64] Proof of concept for re-vectorisation#208213gbossu wants to merge 1 commit into
gbossu wants to merge 1 commit into
Conversation
This shows the changes required to enable basic re-vectorisation support in LoopVectorizer. Most of the diff comes from the added tests, the changes to LoopVectorizer files are rather minimal. This proof-of-concept has obvious limitations and only represents the first building block. My hope is that this helps discussions and complements the RFC at https://discourse.llvm.org/t/rfc-re-vectorisation-to-wider-vectors-in-loopvectorizer/91071. Support for re-vectorisation is hidden behind a -vectorize-vector-loops flag and LV will bail out if it encounters constructs that are not yet supported. For example: - shufflevectors - gather/scatter and interleaved accesses - target intrinsics - reductions - if-conversion or tail folding
You can test this locally with the following command:Build idt from compnerd/ids, then for each changed header:
idt -p build/ --main-file <matching-source.cpp> \
--apply-fixits --inplace <header>View the diff from ids-check here.diff --git a/llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h b/llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
index 25ec10e71..cb1cf4784 100644
--- a/llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
+++ b/llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
@@ -48,7 +48,7 @@ class TargetLibraryInfo;
class TargetTransformInfo;
class Type;
-extern cl::opt<bool> VectorizeVectorLoops;
+extern LLVM_ABI cl::opt<bool> VectorizeVectorLoops;
/// Utility class for getting and setting loop vectorizer hints in the form
/// of loop metadata.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This shows the changes required to enable basic re-vectorisation support in LoopVectorizer. Most of the diff comes from the added tests, the changes to LoopVectorizer files are rather minimal. This proof-of-concept has obvious limitations and only represents the first building block.
My hope is that this helps discussions and complements the RFC at https://discourse.llvm.org/t/rfc-re-vectorisation-to-wider-vectors-in-loopvectorizer/91071.
Support for re-vectorisation is hidden behind a -vectorize-vector-loops flag and LV will bail out if it encounters constructs that are not yet supported. For example:
Note: This is part of a stacked PR to create a proof-of-concept for re-vectorisation in LoopVectorizer.