[LLVMdev] Reasoning about Floating Point in Optimizations
Philip Reames
listmail at philipreames.com
Thu Jun 28 20:13:42 PDT 2012
Good evening all,
Inspired by http://llvm.org/bugs/show_bug.cgi?id=3299, I've spent the
last few hours looking at various test cases involving float point
variables in loops and trying to identify some of our short comings on
the optimization front. Before I go any further, I want to share my
findings with the community and ask for feedback on how best to approach
this.
Essentially, the motivating examples are things like these two:
void func() {
// this loop does not get pruned
for (float i = 0.0f; i < 1000.0f; i += 1.2f) {
}
}
int foo3() {
// this loop does not get pruned
for(int i = 0; i < 1000.0f; i++) {
}
return 0;
}
When the IR is generated and optimized, we are currently unable to
recognize these as fixed trip count loops. As such, we do not optimize
them away. If we extend the second example to compute a running sum of
the indexes, we aren't able to recognize that constant calculation
either. (We do both optimizations if the upper bound constant is
converted to an integer in the second loop.)
Looking into this, I discovered two sets of possible issues:
1) InstCombine does not take advantage of instruction sequences in which
a variable integer is converted to a float and then immediate compared
to a floating point constant. In many cases, these can be converted to
an integer comparison.
%conv = sitofp i32 %0 to float
%cmp = fcmp olt float %conv, 1.000000e+03
2) ScalarEvolution is completely ignorant of floating point values and
doesn't recognize fixed (or even bounded) trip counts. The end result
of this is that the loop appears possible infinite to loop-deletion and
can't be safely deleted.
The general approach I'm considering is to introduce a series of
transformation in InstCombine based on the sitofp/fcmp(const) pattern
and to extend SCEV to be FP aware. The first part doesn't worry me too
much - though I will want a careful review from someone more familiar
with FP semantics than myself - but the second one I'm unsure of. Is
this the right approach to be taking? Or is there a better way to
address this problem?
Note: I'm working off the head of SVN as of around 6pm.
Note 2: I don't have any personal stake in this topic, I just grabbed it
as an interesting case to investigate. If someone is already looking at
this, let me know, I'll go find something else to work on.
Yours,
Philip Reames
More information about the llvm-dev
mailing list