First, thanks a lot for answering.
On Wed, 25 Apr 2012, Richard Guenther wrote:
On Wed, Apr 25, 2012 at 10:12 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
Hello,
a conversion like int->double->int is just the identity, as long as double
is big enough to represent all ints exactly. The most natural way I found to
do this optimization is the attached:
2012-04-25 Marc Glisse <marc.gli...@inria.fr>
PR middle-end/27139
* tree-ssa-forwprop.c (combine_conversions): Handle INT->FP->INT.
Does the approach make sense? I don't know that code, and adding FLOAT_EXPR
/ FIX_TRUNC_EXPR was a bit of guesswork. The precision of double could be
multiplied by log2(base), but not doing it is safe. If the approach is ok, I
could extend it so int->double->long also skips the intermediate conversion.
Bootstrapped and regression tested on linux-x86_64.
Should I try and write a testcase for a specific target checking for
specific asm instructions there, or is there a better way?
Well, scanning the forwprop dump for example.
No idea how that works, but with some grepping and looking at other tests
it shouln't be too hard. I'll try, thanks for the pointer.
Btw, I think not munging this new case into the existing CONVERT_EXPR_P
code would be better - it makes the code (even) harder to understand and
I'm not convinced that adding FLOAT_EXPR/FIX_TRUNC_EXPR handling
does not wreck any assumptions in that code.
Ok.
It also seems that for DECIMAL_FLOAT_TYPE_P the transform is always
valid?
What do you mean? I just tested and my patch does the simplification for
int->_Decimal128->int but not int->_Decimal32->int, which makes sense to
me as _Decimal32 can't represent exactly every int. For _Decimal64, it
doesn't do the simplification although it could, because I didn't multiply
by log2(base), as I said above. I also thought of combining in vrp, where
the range information could make more simplifications valid, but that
seemed harder.
--
Marc Glisse
