This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] Separate jump bypassing pass


Hi Kazu and David,
On Thu, 16 Jan 2003, Kazu Hirata wrote:
> > 2003-01-15  Roger Sayle  <roger@eyesopen.com>
> >
> > 	* gcse.c (one_cprop_pass): Change function arguments to take both
> > 	cprop_jumps and bypass_jumps flags instead of just alter_jumps.
> >     ...
>
> With this patch, gcc seems to cause ICE when compiling
> execute/980526-3.c for H8/300.
> I get
>
> 980526-3.c: In function `foo':
> 980526-3.c:17: internal compiler error: in simplify_subreg,
> at simplify-rtx.c:2248


It looks like that by splitting GCSE and moving jump bypassing
after the loop optimization passes I've fallen foul of some
RTL sharing issues.

In Kazu's example above, 980526-3.c, the RTL prior the the
jump bypassing pass contains:

(insn 13 11 14 0x40018a7c (set (reg:HI 0 r0)
        (subreg:HI (reg:SI 22) 2)) 7 {*h8300.md:266} (nil)
    (expr_list:REG_EQUAL (const_int 1 [0x1])
        (insn_list:REG_LIBCALL 15 (nil))))

(call_insn/u 14 13 15 0x40018a7c (set (reg:HI 0 r0)
        (call (mem:QI (symbol_ref:SI ("bar")) [0 S1 A8])
            (const_int 0 [0x0]))) 80 {call_value} (nil)
    (expr_list:REG_EH_REGION (const_int -1 [0xffffffff])
        (nil))
    (expr_list (use (reg:HI 0 r0))
        (nil)))

(insn 15 14 17 0x40018a7c (set (reg:HI 23)
        (reg:HI 0 r0)) 7 {*h8300.md:266} (nil)
    (insn_list:REG_RETVAL 13 (expr_list:REG_EQUAL (expr_list (symbol_ref:SI ("bar"))
                (expr_list (subreg:HI (reg:SI 22) 2)
                    (nil)))
            (nil))))

In do_local_cprop, we then try substituting "(reg:SI 22)" in insn 13
with "(const_int 1 [0x1])".  The problem is that the RTL expression:
"(subreg:HI (reg:SI 22) 2)" is shared between the SET_SRC in insn 13
and the REG_EQUAL note in insn 15.  So although simplify_subreg can
handle the "(subreg:HI (const_int 1 [0x1]) 2)" in insn 13 because it
knows the mode was formerly SI, by the time "adjust_libcall_notes"
reaches insn 15, subsistution has already been made and the intended
mode of the const_int can't be recovered.


I'm note sure if this sharing of RTL is legal (valid), so I'd like
advice from someone that understands RTL sharing, RTH or Jan?


It looks like David Anglin has also run into the same (or very
similar) problem bootstrapping hppa64-hp-hpux11.11.
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01191.html

Given my ignorance of RTL sharing and a reported bootstrap failure,
we should start the clock ticking and revert the patch if we're no
closer to a solution in a day or so.


Is the above RTL sharing allowed?
If so, do I need to make GCSE avoid cprop in libcalls?
If not, what's the best way to avoid this RTL sharing.
Where is the shared RTL generated, or should I just call
"unshare_all_rtl"?

Many thanks in advance,

Roger
--


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