This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Solaris bootstrap failure


Bernd Schmidt writes:
> On Wed, 7 Mar 2001, Colin Howell wrote:
> 
> > The problem appears to be in cselib_lookup(), which is supposed to
> > find a common subexpression within an insn.  The stage1 compiler finds
> > one for insn 37 of no_linkage_helper() while the stage2 compiler does
> > not.  As a result, the insn is changed by the stage1 compiler but not
> > by the stage2 compiler.  This difference eventually results in the
> > stage1 compiler generating an extra instruction.
> 
> Good detective work so far.  Can you provide more details (rtl or a
> description of the equivalence that is found by stage1)?

Here is insn 37 of no_linkage_helper(), just before
reload_cse_simplify_set() is run on it:

(insn 37 142 38 (set (reg:SI 9 %o1 [150])
        (zero_extend:SI (reg:QI 9 %o1 [117]))) 125 {*zero_extendqisi2_insn} (nil)
    (nil))

On line 8214 of reload1.c, cselib_lookup() is called on the source of
the SET:

(zero_extend:SI (reg:QI 9 %o1 [117]))

In the stage2 compiler, cselib_lookup() finds no equivalence, and so
reload_cse_simplify_set() does nothing to insn 37.

In the stage1 compiler, cselib_lookup() finds the equivalence:

(reg:SI 10 %o2 [113])

So in the stage1 compiler, reload_cse_simplify_set() changes insn 37
to:

(insn 37 142 38 (set (reg:SI 9 %o1 [150])
        (reg:SI 10 %o2 [113])) -1 (nil)
    (nil))

(Note the insn has not yet been rerecognized at this point.)

If you want to know anything else, let me know.

-- 
Colin Douglas Howell            E-mail:  chowell@redhat.com
Support Engineer
Red Hat, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]