Re: optimization/7147: ifcvt.c problem (regression)

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

On Freitag, 28. Juni 2002 00:55, Franz.Sirl-kernel@lauterbach.com wrote:
> >Number:         7147
> >Category:       optimization
> >Synopsis:       ifcvt.c problem (regression)
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    unassigned
> >State:          open
> >Class:          sw-bug
> >Submitter-Id:   net
> >Arrival-Date:   Thu Jun 27 15:56:02 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator:     Franz.Sirl-kernel@lauterbach.com
> >Release:        current gcc-3_1-branch
> >Organization:
> >Environment:
>
> powerpc-linux-gnu
>
> >Description:
>
> This testcase is derived from a reported c++ mozilla miscompilation. It
> fails at -O and works fine with -O -fexpensive-optimizations.
>
> My guess so far is that ifcvt.c is confused by the multiple SETs of pseudo
> 117 (from .rtl):
>
> (insn 27 25 28 (set (reg/v:SI 117)
>         (reg:SI 3 r3)) -1 (nil)
>     (nil))
>
> (insn 28 27 29 (set (reg:CC 120)
>         (compare:CC (reg/v:SI 117)
>             (const_int 0 [0x0]))) -1 (nil)
>     (nil))
>
> (insn 29 28 31 (set (reg/v:SI 117)
>         (eq:SI (reg:CC 120)
>             (const_int 0 [0x0]))) -1 (nil)
>     (nil))
>
> (jump_insn 31 29 32 (set (pc)
>         (label_ref 34)) -1 (nil)
>     (nil))
>
> (barrier 32 31 33)
>
> (note 33 32 34 0x30084680 NOTE_INSN_BLOCK_END)
>
> (code_label 34 33 35 3 ("lab1") "" [0 uses])
>
> (note 35 34 37 0x300846c0 NOTE_INSN_BLOCK_END)
>
> (insn 37 35 38 (set (reg:CC 121)
>         (compare:CC (reg/v:SI 117)
>             (const_int 0 [0x0]))) -1 (nil)
>     (nil))
>
> (jump_insn 38 37 40 (set (pc)
>         (if_then_else (eq (reg:CC 121)
>                 (const_int 0 [0x0]))
>             (label_ref 48)
>             (pc))) -1 (nil)
>     (nil))
>
>
> Somehow the inversion via insn 28 and 29 isn't accounted for.

Actually the inversion is accounted for, but the multiple sets of pseudo reg 
117 seem to confuse the compiler somehow.

Richard, the comment in front of noce_get_condition seems to suggest that you 
weren't satisfied with the use of get_condition here anyway, so maybe 
WANT_REG for canonicalized_condition should always be set to limit the search 
range?

Anyway, the appended patch fixes the testcase for me, running a full bootstrap 
on powerpc-linux-gnu and x86-linux-gnu now.

Franz.

	PR optimization/7147
	* ifcvt.c (noce_get_condition): Use canonicalized_condition directly.
	Limit scan range if !flag_expensive_optimizations.

Attachment: gcc-pr7147.patch
Description: Text document