diff options
| author | Michael Kruse <llvm@meinersbur.de> | 2018-12-18 17:16:05 +0000 |
|---|---|---|
| committer | Michael Kruse <llvm@meinersbur.de> | 2018-12-18 17:16:05 +0000 |
| commit | 3284775b70865581df3f75f6731f7d6464b0f8aa (patch) | |
| tree | 41c37ad09f91aac2bed4a762606fdf9084f9d175 /llvm/test/ExecutionEngine/test-interp-vec-arithm_float.ll | |
| parent | 53b5cfb08035ca02770d6c72752a55742fdd0f5e (diff) | |
| download | bcm5719-llvm-3284775b70865581df3f75f6731f7d6464b0f8aa.tar.gz bcm5719-llvm-3284775b70865581df3f75f6731f7d6464b0f8aa.zip | |
[LoopUnroll] Honor '#pragma unroll' even with -fno-unroll-loops.
When using clang with `-fno-unroll-loops` (implicitly added with `-O1`),
the LoopUnrollPass is not not added to the (legacy) pass pipeline. This
also means that it will not process any loop metadata such as
llvm.loop.unroll.enable (which is generated by #pragma unroll or
WarnMissedTransformationsPass emits a warning that a forced
transformation has not been applied (see
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181210/610833.html).
Such explicit transformations should take precedence over disabling
heuristics.
This patch unconditionally adds LoopUnrollPass to the optimizing
pipeline (that is, it is still not added with `-O0`), but passes a flag
indicating whether automatic unrolling is dis-/enabled. This is the same
approach as LoopVectorize uses.
The new pass manager's pipeline builder has no option to disable
unrolling, hence the problem does not apply.
Differential Revision: https://reviews.llvm.org/D55716
llvm-svn: 349509
Diffstat (limited to 'llvm/test/ExecutionEngine/test-interp-vec-arithm_float.ll')
0 files changed, 0 insertions, 0 deletions
