The problem here is overflow or underflow which would have occurred in
the inner operation, which the exponent offsetting avoids. We can do
this if we know the two exponents are in the same direction, or
reassoc flags allow unsafe reassociates.
Details
Diff Detail
Event Timeline
LGTM.
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
2381–2383 | Additionally it would be safe if both exponents are known to be <= 0, but I guess we don't have a helper function for that. |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
2381–2383 | Right we totally lack FP range tracking |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
2381–2383 | I just mean for the integer exponents, you're checking if they're both < 0, but that could be relaxed to both <= 0. |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
2381–2383 | This checks that they are both positive or both negative so I’m not sure what you mean |
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp | ||
---|---|---|
2381–2383 | Your code optimizes if they are both >= 0 or both < 0. |
Additionally it would be safe if both exponents are known to be <= 0, but I guess we don't have a helper function for that.