aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/InlineFunction.cpp
diff options
context:
space:
mode:
authorDan Gohman <gohman@apple.com>2010-04-22 23:14:21 +0000
committerDan Gohman <gohman@apple.com>2010-04-22 23:14:21 +0000
commitffc9a6b4ac6b979bec1592cfc9f2722f9bb031ed (patch)
treebf41b62cd043e379facaf9be1fab0e81295aab63 /llvm/lib/Transforms/Utils/InlineFunction.cpp
parentf68a50858675856c0fe474b81e7bf3229a00ea0e (diff)
downloadllvm-ffc9a6b4ac6b979bec1592cfc9f2722f9bb031ed.zip
llvm-ffc9a6b4ac6b979bec1592cfc9f2722f9bb031ed.tar.gz
llvm-ffc9a6b4ac6b979bec1592cfc9f2722f9bb031ed.tar.bz2
Add an initial description of a new concept: trap values, and change
the definition of the nsw and nuw flags to make use of it. nsw was introduced to help optimizers answer yes to the following: // Can we change i from i32 to i64 to eliminate the cast inside the loop? for (int i = 0; i < n; ++i) A[i] *= 0.1; // Can we assume that this loop will eventually terminate? for (int i = 0; i <= n; ++i) A[i] *= 0.1; In its current form, it isn't truly sufficient for either. In the first case, if the increment overflows, it'll still have some valid i32 value; sign-extending it will produce a value which is 33 homogeneous sign bits trailed by 31 independent undef bits. If i is promoted to i64, it won't have those same values when it reaches that point. (The compiler could recover here by reasoning about how i is used by the load, but that's a lot more complicated and isn't always possible.) In the second case, there is no value for i which will be greater than n, so having the increment return undef on overflow doesn't help. Trap values are a formalization of some existing concepts that we have about LLVM IR, and give the optimizers a better basis for answering yes to both questions above. llvm-svn: 102140
Diffstat (limited to 'llvm/lib/Transforms/Utils/InlineFunction.cpp')
0 files changed, 0 insertions, 0 deletions