aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/LoopUtils.cpp
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2021-06-10 13:16:50 -0700
committerPhilip Reames <listmail@philipreames.com>2021-06-10 13:20:28 -0700
commitaaaeb4b160fe94e0ad3bcd6073eea4807f84a33a (patch)
tree53a90f4a50c94e991aa6ead783aa1c4b14297774 /llvm/lib/Transforms/Utils/LoopUtils.cpp
parent1d3873d41eca67e974bafbaa91866581bcc0d973 (diff)
downloadllvm-aaaeb4b160fe94e0ad3bcd6073eea4807f84a33a.zip
llvm-aaaeb4b160fe94e0ad3bcd6073eea4807f84a33a.tar.gz
llvm-aaaeb4b160fe94e0ad3bcd6073eea4807f84a33a.tar.bz2
[SCEV] Use mustprogress flag on loops (in addition to function attribute)
This addresses a performance regression reported against 3c6e4191. That change (correctly) limited a transform based on assumed finiteness to mustprogress loops, but the previous change (38540d7) which introduced the mustprogress check utility only handled function attributes, not the loop metadata form. It turns out that clang uses the function attribute form for C++, and the loop metadata form for C. As a result, 3c6e4191 ended up being a large regression in practice for C code as loops weren't being considered mustprogress despite the language semantics.
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUtils.cpp')
0 files changed, 0 insertions, 0 deletions