This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: combine_conversions int->double->int
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 25 Apr 2012 10:59:10 +0200
- Subject: Re: combine_conversions int->double->int
- References: <alpine.DEB.2.02.1204250932210.2541@laptop-mg.saclay.inria.fr>
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.
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.
It also seems that for DECIMAL_FLOAT_TYPE_P the transform is always
valid?
Richard.
> (note that I can't commit)
>
> --
> Marc Glisse