Code generation problem with optimizations enabled

Code generation problem with optimizations enabled

[Jamie Prescott]

Hi!
I have this little code that drives me crazy about the code generation (GCC 4.3.3).

extern double tle_mk_inf(int);

double tle_exp(double dval)
{
        if (dval == 0.0)
                return 0.0;
        if (dval > 10000)
                return tle_mk_inf(1);

        return -1.2;
}


If I compiled it with -O2 or -O3, the insn output is missing an 'fcmp' ('cmpdf'), like you can see below:


$LC0:
        long   0
        long   0
$LC1:
        long   0
        long   1086556160
$LC2:
        long   858993459
        long   -1074580685

_tle_exp:
        push    FP
        mov     SP,FP
        push    r8
        fpush   x8
        lea     $LC0,r8
        ldr.f    r8,x8
        fcmp    x0,x8
        jz $L4
        lea     $LC1,r8
        ldr.f    r8,x8
<<<<<< MISSING 'fcmp x0,x8'
        ja $L5
        lea     $LC2,r8
        ldr.f    r8,x8
$L4:
        fdmov   x8,x0
        fpop    x8
        pop     r8
        mov     FP,SP
        pop     FP
        ret
$L5:
        mov     1,r0
        call   _tle_mk_inf
        fpop    x8
        pop     r8
        mov     FP,SP
        pop     FP
        ret


If I disable the optimizations, everything is fine and the 'fcmp' is there.
Even with optimizations enabled, the RTL dump shows the missing 'cmpdf' present
and correctly recognized. It being:

(define_insn "cmpdf"
  [(set (cc0)
        (compare (match_operand:DF 0 "fullreg_operand" "x")
                 (match_operand:DF 1 "fullreg_operand" "x")))]
  ""
  "fcmp\t%0,%1"
  [
   (set_attr "length" "3")
   (set_attr "cc" "compare")
  ]
)


Any hints?



 - Jamie



      

Re: Code generation problem with optimizations enabled

[Jamie Prescott]

----- Original Message ----

> From: Jamie Prescott <jpresss@yahoo.com>
> To: gcc@gcc.gnu.org
> Sent: Monday, May 11, 2009 11:59:23 PM
> Subject: Code generation problem with optimizations enabled

> If I disable the optimizations, everything is fine and the 'fcmp' is there.
> Even with optimizations enabled, the RTL dump shows the missing 'cmpdf' present
> and correctly recognized. It being:

What I noticed is that if I CC_STATUS_INIT (in xxx_notice_update_cc()) even for insn that
do not require it (that are almost all of them - being only cmp/fcmp/test that modify cc0),
cmpdf gets emitted regularly.
Normally all the insn but cmp/fcmp/test set "none" in their cc attribute, and
xxx_notice_update_cc() does nothing in that case.
While cmp and fcmp (that set the cc attribute to "compare") do CC_STATUS_INIT and
records DEST and SRC operands.
Am I doing it wrong?


- Jamie


      

Re: Code generation problem with optimizations enabled

[Paolo Bonzini]

> What I noticed is that if I CC_STATUS_INIT (in xxx_notice_update_cc()) even for insn that
> do not require it (that are almost all of them - being only cmp/fcmp/test that modify cc0),
> cmpdf gets emitted regularly.

If so, you should not be using cc0, but a CCmode register instead.

See for example how the fr30 port implements compare-and-jump.  I'm
currently committing a merge that changes a bit how the
compare-and-jumps are realized; if you wait a few hours, you'll get a
more up-to-date example.

Paolo

Re: Code generation problem with optimizations enabled

[Jamie Prescott]

Thank you Paolo, I'll take a look at it.
Is there a reason why the fcmp insn was dropped with such implementation?


 - Jamie



----- Original Message ----
> From: Paolo Bonzini <bonzini@gnu.org>
> To: Jamie Prescott <jpresss@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Sent: Tuesday, May 12, 2009 1:31:53 AM
> Subject: Re: Code generation problem with optimizations enabled
> 
> > What I noticed is that if I CC_STATUS_INIT (in xxx_notice_update_cc()) even 
> for insn that
> > do not require it (that are almost all of them - being only cmp/fcmp/test that 
> modify cc0),
> > cmpdf gets emitted regularly.
> 
> If so, you should not be using cc0, but a CCmode register instead.
> 
> See for example how the fr30 port implements compare-and-jump.  I'm
> currently committing a merge that changes a bit how the
> compare-and-jumps are realized; if you wait a few hours, you'll get a
> more up-to-date example.
> 
> Paolo



      

Re: Code generation problem with optimizations enabled

[Jamie Prescott]

----- Original Message ----

> From: Paolo Bonzini <bonzini@gnu.org>
> To: Jamie Prescott <jpresss@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Sent: Tuesday, May 12, 2009 1:31:53 AM
> Subject: Re: Code generation problem with optimizations enabled
> 
> > What I noticed is that if I CC_STATUS_INIT (in xxx_notice_update_cc()) even 
> for insn that
> > do not require it (that are almost all of them - being only cmp/fcmp/test that 
> modify cc0),
> > cmpdf gets emitted regularly.
> 
> If so, you should not be using cc0, but a CCmode register instead.
> 
> See for example how the fr30 port implements compare-and-jump.  I'm
> currently committing a merge that changes a bit how the
> compare-and-jumps are realized; if you wait a few hours, you'll get a
> more up-to-date example.

Thanks Paolo, that worked great and simplified things quite a bit.


- Jamie


      

Re: Code generation problem with optimizations enabled

[Jim Wilson]

Jamie Prescott wrote:
> Thank you Paolo, I'll take a look at it.
> Is there a reason why the fcmp insn was dropped with such implementation?

The code that optimizes away redundant cc0 compares is in final.c, in 
final_scan_insn().  It is about line 2310 in my tree, near the comment 
"Check for redundant test and compare instructions".  Try stepping 
through that code to see what is going on.  Maybe you are setting 
cc_status.value1 but not cc_status.value2?

In any case, as Paolo mentioned, you are better off not using cc0.  cc0 
should only be used if you have no other choice.  And even then, you 
still probably shouldn't use it.  Every couple of years someone tries to 
eliminate the cc0 code, and eventually someone will succeed.

Jim

Re: Code generation problem with optimizations enabled

[Jamie Prescott]

----- Original Message ----
> From: Jim Wilson <wilson@codesourcery.com>
> To: Jamie Prescott <jpresss@yahoo.com>
> Cc: Paolo Bonzini <bonzini@gnu.org>; gcc@gcc.gnu.org
> Sent: Wednesday, May 13, 2009 6:15:07 PM
> Subject: Re: Code generation problem with optimizations enabled
> 
> Jamie Prescott wrote:
> > Thank you Paolo, I'll take a look at it.
> > Is there a reason why the fcmp insn was dropped with such implementation?
> 
> The code that optimizes away redundant cc0 compares is in final.c, in 
> final_scan_insn().  It is about line 2310 in my tree, near the comment "Check 
> for redundant test and compare instructions".  Try stepping through that code to 
> see what is going on.  Maybe you are setting cc_status.value1 but not 
> cc_status.value2?
> 
> In any case, as Paolo mentioned, you are better off not using cc0.  cc0 should 
> only be used if you have no other choice.  And even then, you still probably 
> shouldn't use it.  Every couple of years someone tries to eliminate the cc0 
> code, and eventually someone will succeed.

Thanks for the insight. But anyway, I took the path Paolo told me using CCmode and
now it's working nicely.


- Jamie