combine_conversions int->double->int

[Marc Glisse]

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.glisse@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.glisse@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