This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Separate jump bypassing pass
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>, John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>
- Date: Thu, 16 Jan 2003 19:24:22 -0700 (MST)
- Subject: 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
--