[Bug target/17390] missing floating point compare optimization

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From hubicka at ucw dot cz  2004-09-10 09:48 -------
Subject: Re:  missing floating point compare optimization

> 
> ------- Additional Comments From uros at kss-loka dot si  2004-09-10 08:39 -------
> Some comments here:
> 
> http://gcc.gnu.org/ml/gcc/2004-09/msg00413.html
> http://gcc.gnu.org/ml/gcc/2004-09/msg00514.html
> 
> For TARGET_CMOVE, resulting code is totally different:
> 
> test:
>         fldz
>         fldl    4(%esp)
>         fcomip  %st(1), %st
>         je      .L11
>         fstp    %st(0)
>         flds    .LC1
>         fld1
>         fcmovbe %st(1), %st
>         fstp    %st(1)
> .L11:
>         ret
> 
> It looks that the problem is because  ix86_split_fp_branch() from *fp_jcc_?
> patterns is called after "reload_completed". However, the comment on top says:
> 
> ;; Define combination compare-and-branch fp compare instructions to use
> ;; during early optimization.  Splitting the operation apart early makes
> ;; for bad code when we want to reverse the operation.
> 
> It is not clear to me, what is meant by "reverse the operation"...

If you throw unwound sequence to the compiler early (having all the
funky bits with 387 control word, stores to memory and stuff..) you end
up with compiler no longer being able to modify the conditional in any
resonable way.
It is quite important to be able to reverse the conditional, swap
operands and determine constant result during the optimization.

The code here simply makes "fake" compare & branch FP instruction that
is later in the game decomposed into the true magic.  This idea however
unfortunately kills the idea of reusing the control word for multiple
comparisons.  Simply this scheme trades this quite uncommon
transformation for being able to do something with the conditionals.
Actually with tree-ssa we might try to revisit the idea - you might just
play around with the splitting early and doing some benchmark what
difference it still makes.

Things gets easier when fcomip instruction is available, I think we can
just try expose the decoposed sequence then as it is plain
compare&branch sequence in the case this is not done already.

Honza
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390