1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-18 18:42:46 +02:00
llvm-mirror/include/llvm/Transforms/Vectorize
Joachim Meyer 6b73f118b0 [LV] Parallel annotated loop does not imply all loads can be hoisted.
As noted in https://bugs.llvm.org/show_bug.cgi?id=46666, the current behavior of assuming if-conversion safety if a loop is annotated parallel (`!llvm.loop.parallel_accesses`), is not expectable, the documentation for this behavior was since removed from the LangRef again, and can lead to invalid reads.
This was observed in POCL (https://github.com/pocl/pocl/issues/757) and would require similar workarounds in current work at hipSYCL.

The question remains why this was initially added and what the implications of removing this optimization would be.
Do we need an alternative mechanism to propagate the information about legality of if-conversion?
Or is the idea that conditional loads in `#pragma clang loop vectorize(assume_safety)` can be executed unmasked without additional checks flawed in general?
I think this implication is not part of what a user of that pragma (and corresponding metadata) would expect and thus dangerous.

Only two additional tests failed, which are adapted in this patch. Depending on the further direction force-ifcvt.ll should be removed or further adapted.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D103907
2021-06-10 23:37:57 +02:00
..
LoadStoreVectorizer.h
LoopVectorizationLegality.h [LV] Parallel annotated loop does not imply all loads can be hoisted. 2021-06-10 23:37:57 +02:00
LoopVectorize.h Reland "[LV] Calculate max feasible scalable VF." 2021-05-04 15:44:41 +01:00
SLPVectorizer.h [SLP] Add insertelement instructions to vectorizable tree 2021-05-13 07:41:45 +03:00
VectorCombine.h [llvm] Fix header guards (NFC) 2021-02-05 21:02:06 -08:00