Re: GCC 3.3.1 -O2 problem with sqrt.c

[Sanjiv Kumar Gupta <skgnu at yahoo dot com>]

--- Ian Lance Taylor <ian@airs.com> wrote:

> Sanjiv Kumar Gupta <sanjiv.gupta@oracle.com> writes:
> 
> > >>I couldn't understand why the insns 620 and 621
> are
> > >>being generated here as DI moves.
> > > I'm not sure specifically why it got a DI move
> here, but it doesn't
> > > look wrong.  It's treating the struct named
> parts as DImode.
> > >
> > >>This is creating problem since insn 621 gets
> splitted
> > >>after reload into two SI moves,i.e. @(r21, -8)
> and
> > >>@(r21, -4).
> > >>This renders insns 619 as dead and hence insns
> 618 and
> > >>insn 429 as dead, which are eliminated by flow2.
> > > It does look rather suspicious, but it's hard to
> know whether it is
> > > wrong without seeing the value in r1.
> > >
> > r1 looks unrelated to struct members, and is being
> used by the
> > ifcvt pass to expand some comparison insns.
> 
> In your .23 file, this is insn 431:
> 
> (insn 431 430 432 39 0x1002f420 (set (subreg:SI
> (reg/v:DI 153) 0)
>         (reg/v:SI 77)) 6 {*movsi} (insn_list 429
> (nil))
>     (expr_list:REG_DEAD (reg/v:SI 77)
>         (nil)))
> 
> So it is setting the first SI subreg of a DI value. 
> reload decides to
> do an output reload for register 153.  Since
> register 153 is DImode,
> it does a DImode reload.
> 
> It winds up copying the DImode value to r2, and then
> writing r2 to
> memory.  The double move is because there is a
> secondary reload
> involved.  That implies that
> SECONDARY_OUTPUT_RELOAD_CLASS is defined
> and is returning something other than NO_REGS for
> this case.
> 
> I see that insn 429 is setting the high part of
> register 153.  Insn
> 429 looks like this:
> 
> (insn 429 428 430 39 0x1002f420 (set (subreg:SI
> (reg/v:DI 153) 4)
>         (plus:SI (reg/v:SI 79)
>             (reg/v:SI 82))) 12 {addsi3} (insn_list
> 422 (nil))
>     (expr_list:REG_DEAD (reg/v:SI 82)
>         (expr_list:REG_DEAD (reg/v:SI 79)
>             (nil))))
> 
> But note that a set to a subreg is explicitly
> defined to set the other
> parts of the register to garbage.  Therefore the
> value set by insn 429
> is destroyed by insn 431.
> 
> I would guess that you need a strict_low_part in
> insns 429 and 431.
> See the RTL documentation.
> 
> Ian
> 
Thanks Ian for your inputs. The problem got solved.
There was no intermediate reg needed for this reload.
But I still feel that a strict_low_part would be
needed as you suggested.

Thanks again.

Sanjiv

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com