Changes in optsize.ll

872f7000 - Revert "[NFCI] Regenerate SROA/LoopVectorize test checks"

Sun, 03 Apr 2022 23:14:34 +0000

Revert "[NFCI] Regenerate SROA/LoopVectorize test checks"This reverts commit 14e3450fb57305aa9ff3e9e60687b458e43835c9. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

a113a582 - [NFCI] Regenerate LoopVectorize test checks

Sun, 03 Apr 2022 19:55:58 +0000

[NFCI] Regenerate LoopVectorize test checks List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

95f76bff - [LV] Create & use VPScalarIVSteps for all scalar users.

Sun, 13 Mar 2022 17:15:24 +0000

[LV] Create & use VPScalarIVSteps for all scalar users.This patch is a follow-up to D115953. It updates optimizeInductionsto also introduce new VPScalarIVStepsRecipes if an IV has both vectorand scalar uses.It updates all uses that only need scalar values to use the newlycreated recipe for the scalar steps.This completes untangling of VPWidenIntOrFpInductionRecipecode-generation. Now the recipe *only* creates the widened vectorvalues, as it says on the tin.The code to genereate IR has been moved directly toVPWidenIntOrFpInductionRecipe::execute.Note that the recipe has been updated to hold a reference toScalarEvolution, which is needed to expand the step, until we can placethe corresponding SCEV expansion in the pre-header.Depends on D120827.Reviewed By: AyalDifferential Revision: https://reviews.llvm.org/D120828 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

efd49387 - [VPlan] Handle IV vector splat using VPWidenCanonicalIV.

Sat, 29 Jan 2022 16:22:18 +0000

[VPlan] Handle IV vector splat using VPWidenCanonicalIV.This patch tries to use an existing VPWidenCanonicalIVRecipeinstead of creating another step-vector for canonicalinduction recipes in widenIntOrFpInduction.This has the following benefits: 1. First step to avoid setting both vector and scalar values for the same induction def. 2. Reducing complexity of widenIntOrFpInduction through making things more explicit in VPlan 3. Only need to splat the vector IV for block in masks.Reviewed By: AyalDifferential Revision: https://reviews.llvm.org/D116123 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

23c2f2e6 - [LV] Mark increment of main vector loop induction variable as NUW.

Mon, 07 Jun 2021 08:24:27 +0000

[LV] Mark increment of main vector loop induction variable as NUW.This patch marks the induction increment of the main induction variableof the vector loop as NUW when not folding the tail.If the tail is not folded, we know that End - Start >= Step (eitherstatically or through the minimum iteration checks). We also know that bothStart % Step == 0 and End % Step == 0. We exit the vector loop if %IV +%Step == %End. Hence we must exit the loop before %IV + %Step unsignedoverflows and we can mark the induction increment as NUW.This should make SCEV return more precise bounds for the created vectorloops, used by later optimizations, like late unrolling.At the moment quite a few tests still need to be updated, but beforedoing so I'd like to get initial feedback to make sure I am not missinganything.Note that this could probably be further improved by using informationfrom the original IV.Attempt of modeling of the assumption in Alive2:https://alive2.llvm.org/ce/z/H_DL_gPart of a set of fixes required for PR50412.Reviewed By: mkazantsevDifferential Revision: https://reviews.llvm.org/D103255 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

4a8e6ed2 - [SLP,LV] Use poison constant vector for shufflevector/initial insertelement

Tue, 05 Jan 2021 05:11:50 +0000

[SLP,LV] Use poison constant vector for shufflevector/initial insertelementThis patch makes SLP and LV emit operations with initial vectors set to poison constant instead of undef.This is a part of efforts for using poison vector instead of undef to represent "doesn't care" vector.The goal is to make nice shufflevector optimizations valid that is currently incorrect due to the tricky interaction between undef and poison (see https://bugs.llvm.org/show_bug.cgi?id=44185 ).Reviewed By: fhahnDifferential Revision: https://reviews.llvm.org/D94061 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

278aa65c - [IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholder

Thu, 24 Dec 2020 00:33:58 +0000

[IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholderThis patch updates IRBuilder to create insertelement/shufflevector using poison as a placeholder.Reviewed By: nikicDifferential Revision: https://reviews.llvm.org/D93793 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

be6e8e50 - [LV] Tail folded inloop reductions.

Sun, 11 Oct 2020 15:58:34 +0000

[LV] Tail folded inloop reductions.This expands upon the inloop reductions added in e9761688e41cb9e976,allowing them to be inserted into tail folded loops. Reductions aregenerates with the form: x = select(mask, vecop, zero) v = vecreduce.add(x) c = add chain, vWhere zero here is chosen as the identity value for add reductions. Thebackend is then expected to fold the select and the vecreduce into asingle predicated instruction.Most of the code is fairly straight forward, except for the creation ofblockmasks which need to ensure they are created in dominance order. Theorder they are added is altered to be after any phis, keeping therequirements for the underlying IR.Differential Revision: https://reviews.llvm.org/D84451 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

7bf299c8 - [LV] Vectorize without versioning-for-unit-stride under -Os/-Oz

Sun, 07 Jun 2020 08:36:57 +0000

[LV] Vectorize without versioning-for-unit-stride under -Os/-OzIf a loop is in a function marked OptSize, Loop Access Analysis should refrainfrom generating runtime checks for unit strides that will version the loop.If a loop is in a function marked OptSize and its vectorization is enabled, itshould be vectorized w/o any versioning.Fixes PR46228.Differential Revision: https://reviews.llvm.org/D81345 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

0deab8a5 - [LV] Either get invariant condition OR vector condition.

Sun, 24 May 2020 13:14:43 +0000

[LV] Either get invariant condition OR vector condition.Currently we unconditionally get the first lane of the conditionoperand, even if we later use the full vector condition. This can resultin some unnecessary instructions being generated.Suggested as follow-up in D80219. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

9529597c - Recommit #2: "[LV] Induction Variable does not remain scalar under tail-folding."

Tue, 12 May 2020 19:23:09 +0000

Recommit #2: "[LV] Induction Variable does not remain scalar under tail-folding."This was reverted because of a miscompilation. At closer inspection, theproblem was actually visible in a changed llvm regression test too. Thisone-line follow up fix/recommit will splat the IV, which is what we are tryingto avoid if unnecessary in general, if tail-folding is requested even if allusers are scalar instructions after vectorisation. Because with tail-folding,the splat IV will be used by the predicate of the masked loads/storesinstructions. The previous version omitted this, which caused themiscompilation. The original commit message was:If tail-folding of the scalar remainder loop is applied, the primary inductionvariable is splat to a vector and used by the masked load/store vectorinstructions, thus the IV does not remain scalar. Because we now markthat the IV does not remain scalar for these cases, we don't emit the vector IVif it is not used. Thus, the vectoriser produces less dead code.Thanks to Ayal Zaks for the direction how to fix this. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

f936457f - Revert "Recommit "[LV] Induction Variable does not remain scalar under tail-folding.""

Fri, 08 May 2020 12:48:17 +0000

Revert "Recommit "[LV] Induction Variable does not remain scalar under tail-folding.""This reverts commit ae45b4dbe73ffde5fe3119835aa947d5a49635ed. Itcauses miscompilations, test case on the mailing list. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

ae45b4db - Recommit "[LV] Induction Variable does not remain scalar under tail-folding."

Thu, 07 May 2020 10:10:15 +0000

Recommit "[LV] Induction Variable does not remain scalar under tail-folding."With 3 llvm regr tests fixed/updated that I had missed. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

20d67ffe - Revert "[LV] Induction Variable does not remain scalar under tail-folding."

Thu, 07 May 2020 08:29:56 +0000

Revert "[LV] Induction Variable does not remain scalar under tail-folding."This reverts commit 617aa64c84146468b384453375d1d34f97eb57db.while I investigate buildbot failures. List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

617aa64c - [LV] Induction Variable does not remain scalar under tail-folding.

Thu, 07 May 2020 08:03:59 +0000

[LV] Induction Variable does not remain scalar under tail-folding.If tail-folding of the scalar remainder loop is applied, the primary inductionvariable is splat to a vector and used by the masked load/store vectorinstructions, thus the IV does not remain scalar. Because we now markthat the IV does not remain scalar for these cases, we don't emit the vector IVif it is not used. Thus, the vectoriser produces less dead code.Thanks to Ayal Zaks for the direction how to fix this.Differential Revision: https://reviews.llvm.org/D78911 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

cee313d2 - Revert "Temporarily Revert "Add basic loop fusion pass.""

Wed, 17 Apr 2019 04:52:47 +0000

Revert "Temporarily Revert "Add basic loop fusion pass.""The reversion apparently deleted the test/Transforms directory.Will be re-reverting again.llvm-svn: 358552 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

45a3ca7b - [LV] Avoid vectorizing loops under opt for size that involve SCEV checks

Fri, 02 Nov 2018 09:16:12 +0000

[LV] Avoid vectorizing loops under opt for size that involve SCEV checksFix PR39417, PR39497The loop vectorizer may generate runtime SCEV checks for overflow and stride==1cases, leading to execution of original scalar loop. The latter is forbiddenwhen optimizing for size. An assert introduced in r344743 triggered the abovePR's showing it does happen. This patch fixes this behavior by preventingvectorization in such cases.Differential Revision: https://reviews.llvm.org/D53612llvm-svn: 345959 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

b0b5312e - [LV] Fold tail by masking to vectorize loops of arbitrary trip count under opt for size

Thu, 18 Oct 2018 15:03:15 +0000

[LV] Fold tail by masking to vectorize loops of arbitrary trip count under opt for sizeWhen optimizing for size, a loop is vectorized only if the resulting vector loopcompletely replaces the original scalar loop. This holds if no runtime guardsare needed, if the original trip-count TC does not overflow, and if TC is aknown constant that is a multiple of the VF. The last two TC-related conditionscan be overcome by1. rounding the trip-count of the vector loop up from TC to a multiple of VF;2. masking the vector body under a newly introduced "if (i <= TC-1)" condition.The patch allows loops with arbitrary trip counts to be vectorized under -Os,subject to the existing cost model considerations. It also applies to loops withsmall trip counts (under -O2) which are currently handled as if under -Os.The patch does not handle loops with reductions, live-outs, or w/o a primaryinduction variable, and disallows interleave groups.(Third, final and main part of -)Differential Revision: https://reviews.llvm.org/D50480llvm-svn: 344743 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll

1a871304 - [LV] Add test checks when vectorizing loops under opt for size; NFC

Tue, 16 Oct 2018 14:25:02 +0000

[LV] Add test checks when vectorizing loops under opt for size; NFCLanding this as a separate part of https://reviews.llvm.org/D50480, recordingcurrent behavior more accurately, to clarify subsequent diff ([LV] Vectorizingloops of arbitrary trip count without remainder under opt for size).llvm-svn: 344606 List of files: /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/X86/optsize.ll