User Details
- User Since
- Sep 10 2021, 3:24 AM (72 w, 2 d)
Oct 4 2022
Oct 3 2022
Sep 28 2022
Sep 26 2022
Refactor `isInvariantStoreOfReduction' check
Sep 22 2022
Update commit message
Fixes
Sep 13 2022
Sep 12 2022
Add an empty line to the test and a reference to the github issue
This is a bug fix for - https://github.com/llvm/llvm-project/issues/57572
Jun 7 2022
This patch actually also enables support for the cases where we have potentially conflicting accesses that have different strides (well invariant read is technically stride equal to zero). Here's one more real-live example:
May 5 2022
May 3 2022
Address 'nits' requests
Apr 28 2022
Apr 27 2022
Lots of updates related to the recent comments
Apr 25 2022
@fhahn, @david-arm ping. Also I run lnt test-suite and everything is fine and 17 more loops were vectorized according to -stats
Mar 28 2022
@fhahn, gentle ping :)
Mar 15 2022
Fix incorrectly processed case when reduction value stored in invariant could be overwritten inside loop
Feb 17 2022
Add full vector.body and middle.block checks for reduc_store and reduc_store_inside_unrolled tests
Feb 7 2022
Feb 4 2022
@kkwli0 Hi, is it useful to run this test outside of x86? We on aarch64 had the same problem as the on addressed by a64797b5b81963a8d4bc73eaacabfee67c85c679. Alternatively I can just // UNSUPPORTED: aarch64 instead of // REQUIRES: x86-registered-target but there is a chance those clauses will be needed for the other architectures too.
Add fix that prevents vectorization for the case when not a final reduction value stored in a loop invariant address.
Add test for this case.
Remove some unused code and rename a couple of IR variables in the reduction-with-invariant-store.ll test.
Fix incorrect phi node in reduc_store_inside_unrolled and reduc_double_invariant_store tests.
Jan 27 2022
Add invariant store information to VReductionRecipe::print output
Jan 25 2022
Update tests
Jan 24 2022
@fhahn, yes, I have access, I'll submit changes in a moment.
Final updates
Jan 20 2022
@fhahn ping
Jan 13 2022
@lebedev.ri This patch addresses a different problem. Here we try to handle when a reduction value is stored in some address and if this address is invariant plus other lucky conditions are satisfied we manage to vectorize. In your example address where value is stored is not invariant at all. Nevertheless, the case is interesting.
@fhahn I created the review with tests only here - https://reviews.llvm.org/D117213. Once it is merged I'll update this one.
Update tests, move invariant store tests into separate file, add more comments
Dec 21 2021
@fhahn ping
Dec 6 2021
Hi, @fhahn! Since there have been several quite serious changes in the patch after your last review, I would be happy to receive you approval before merge (even though status is accepted now).
Nov 29 2021
Lots of updates related to the recent comments
Nov 26 2021
Nov 25 2021
Update comment
Nov 23 2021
Fix typo
Nov 22 2021
Little extension in a new test
Add scalable reduction test
Nov 18 2021
Refactoring a bit
Add test
Update tests
Nov 10 2021
Nov 9 2021
Update intermediate store check for ordered fadd vectorization
Nov 7 2021
Update commit message and comments
Move storeToSameAddress to ScalarEvolution
Add fadd fast test
Do not apply patch for ordered fadd reductions
Nov 1 2021
Remove my old test for the change
Update test, remove redundant code
Oct 27 2021
Oct 13 2021
It seems like the main problem is that we potentially bail out too early at the moment when checking for reductions due to the store, but once we generate runtime checks, sinking the store may become legal (see inline comment about loads to the same address)? If that's the case, ideally we'd just sink any such loads/stores before detecting reductions once we know they can be sunk due to runtime checks, but unfortunately I do not think that's possible with the current structure/ordering.
Oct 10 2021
Update comment
Updating D110235