* ifcvt pass ordering
@ 2002-10-16 11:24 Jan Hubicka
2002-10-25 13:57 ` Richard Henderson
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Jan Hubicka @ 2002-10-16 11:24 UTC (permalink / raw)
To: gcc-patches, rth
Hi,
Robert's patch to disable early ifcvt passes had unwanted effect of
disabling almost all ifcvt with -ftracer. -ftracer usually duplicates
code to make ifcvt impossible so we must run at least one pass before.
I would like to see this in the mainline too, but technically it is not
regression, so I would be happy with BIB branch too.
Wed Oct 16 20:23:12 CEST 2002 Jan Hubicka <jh@suse.cz>
* toplev.c (dump_file_index): Add DFI_ce3.
(dump_file_info): Likewise.
(rest_of_compilation): Run first ifcvt pass before tracer.
Index: toplev.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/toplev.c,v
retrieving revision 1.668.4.6
diff -c -3 -p -r1.668.4.6 toplev.c
*** toplev.c 15 Oct 2002 01:33:02 -0000 1.668.4.6
--- toplev.c 16 Oct 2002 18:20:19 -0000
*************** enum dump_file_index
*** 232,242 ****
DFI_loop,
DFI_cfg,
DFI_bp,
DFI_tracer,
DFI_cse2,
DFI_life,
DFI_combine,
! DFI_ce,
DFI_regmove,
DFI_sched,
DFI_lreg,
--- 232,243 ----
DFI_loop,
DFI_cfg,
DFI_bp,
+ DFI_ce1,
DFI_tracer,
DFI_cse2,
DFI_life,
DFI_combine,
! DFI_ce2,
DFI_regmove,
DFI_sched,
DFI_lreg,
*************** enum dump_file_index
*** 245,251 ****
DFI_flow2,
DFI_peephole2,
DFI_rnreg,
! DFI_ce2,
DFI_sched2,
DFI_stack,
DFI_bbro,
--- 246,252 ----
DFI_flow2,
DFI_peephole2,
DFI_rnreg,
! DFI_ce3,
DFI_sched2,
DFI_stack,
DFI_bbro,
*************** static struct dump_file_info dump_file[D
*** 278,290 ****
{ "addressof", 'F', 0, 0, 0 },
{ "gcse", 'G', 1, 0, 0 },
{ "loop", 'L', 1, 0, 0 },
{ "cfg", 'f', 1, 0, 0 },
{ "bp", 'b', 1, 0, 0 },
{ "tracer", 'T', 1, 0, 0 },
{ "cse2", 't', 1, 0, 0 },
{ "life", 'f', 1, 0, 0 }, /* Yes, duplicate enable switch. */
{ "combine", 'c', 1, 0, 0 },
! { "ce", 'C', 1, 0, 0 },
{ "regmove", 'N', 1, 0, 0 },
{ "sched", 'S', 1, 0, 0 },
{ "lreg", 'l', 1, 0, 0 },
--- 279,292 ----
{ "addressof", 'F', 0, 0, 0 },
{ "gcse", 'G', 1, 0, 0 },
{ "loop", 'L', 1, 0, 0 },
+ { "ce1", 'C', 1, 0, 0 },
{ "cfg", 'f', 1, 0, 0 },
{ "bp", 'b', 1, 0, 0 },
{ "tracer", 'T', 1, 0, 0 },
{ "cse2", 't', 1, 0, 0 },
{ "life", 'f', 1, 0, 0 }, /* Yes, duplicate enable switch. */
{ "combine", 'c', 1, 0, 0 },
! { "ce2", 'C', 1, 0, 0 },
{ "regmove", 'N', 1, 0, 0 },
{ "sched", 'S', 1, 0, 0 },
{ "lreg", 'l', 1, 0, 0 },
*************** static struct dump_file_info dump_file[D
*** 293,299 ****
{ "flow2", 'w', 1, 0, 0 },
{ "peephole2", 'z', 1, 0, 0 },
{ "rnreg", 'n', 1, 0, 0 },
! { "ce2", 'E', 1, 0, 0 },
{ "sched2", 'R', 1, 0, 0 },
{ "stack", 'k', 1, 0, 0 },
{ "bbro", 'B', 1, 0, 0 },
--- 295,301 ----
{ "flow2", 'w', 1, 0, 0 },
{ "peephole2", 'z', 1, 0, 0 },
{ "rnreg", 'n', 1, 0, 0 },
! { "ce3", 'E', 1, 0, 0 },
{ "sched2", 'R', 1, 0, 0 },
{ "stack", 'k', 1, 0, 0 },
{ "bbro", 'B', 1, 0, 0 },
*************** rest_of_compilation (decl)
*** 2996,3001 ****
--- 2998,3015 ----
close_dump_file (DFI_bp, print_rtl_with_bb, insns);
timevar_pop (TV_BRANCH_PROB);
}
+ if (flag_if_conversion)
+ {
+ timevar_push (TV_IFCVT);
+ if (rtl_dump_file)
+ dump_flow_info (rtl_dump_file);
+ open_dump_file (DFI_ce1, decl);
+ cleanup_cfg (CLEANUP_EXPENSIVE);
+ reg_scan (insns, max_reg_num (), 0);
+ if_convert (0);
+ close_dump_file (DFI_ce1, print_rtl_with_bb, get_insns ());
+ timevar_pop (TV_IFCVT);
+ }
if (flag_tracer)
{
timevar_push (TV_TRACER);
*************** rest_of_compilation (decl)
*** 3020,3035 ****
if (flag_rerun_cse_after_loop)
{
timevar_push (TV_JUMP);
-
reg_scan (insns, max_reg_num (), 0);
- timevar_push (TV_IFCVT);
cleanup_cfg (CLEANUP_EXPENSIVE);
- if (flag_if_conversion)
- if_convert (0);
- timevar_pop (TV_IFCVT);
-
- timevar_pop (TV_JUMP);
/* CFG is no longer maintained up-to-date. */
reg_scan (insns, max_reg_num (), 0);
tem = cse_main (insns, max_reg_num (), 1, rtl_dump_file);
--- 3034,3043 ----
if (flag_rerun_cse_after_loop)
{
timevar_push (TV_JUMP);
reg_scan (insns, max_reg_num (), 0);
+ timevar_pop (TV_JUMP);
cleanup_cfg (CLEANUP_EXPENSIVE);
/* CFG is no longer maintained up-to-date. */
reg_scan (insns, max_reg_num (), 0);
tem = cse_main (insns, max_reg_num (), 1, rtl_dump_file);
*************** rest_of_compilation (decl)
*** 3128,3140 ****
if (flag_if_conversion)
{
timevar_push (TV_IFCVT);
! open_dump_file (DFI_ce, decl);
no_new_pseudos = 0;
if_convert (1);
no_new_pseudos = 1;
! close_dump_file (DFI_ce, print_rtl_with_bb, insns);
timevar_pop (TV_IFCVT);
}
--- 3136,3148 ----
if (flag_if_conversion)
{
timevar_push (TV_IFCVT);
! open_dump_file (DFI_ce2, decl);
no_new_pseudos = 0;
if_convert (1);
no_new_pseudos = 1;
! close_dump_file (DFI_ce2, print_rtl_with_bb, insns);
timevar_pop (TV_IFCVT);
}
*************** rest_of_compilation (decl)
*** 3410,3420 ****
if (flag_if_conversion2)
{
timevar_push (TV_IFCVT2);
! open_dump_file (DFI_ce2, decl);
if_convert (1);
! close_dump_file (DFI_ce2, print_rtl_with_bb, insns);
timevar_pop (TV_IFCVT2);
}
#ifdef STACK_REGS
--- 3418,3428 ----
if (flag_if_conversion2)
{
timevar_push (TV_IFCVT2);
! open_dump_file (DFI_ce3, decl);
if_convert (1);
! close_dump_file (DFI_ce3, print_rtl_with_bb, insns);
timevar_pop (TV_IFCVT2);
}
#ifdef STACK_REGS
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-16 11:24 ifcvt pass ordering Jan Hubicka
@ 2002-10-25 13:57 ` Richard Henderson
2002-10-25 14:07 ` Jan Hubicka
2002-10-26 14:57 ` Geoff Keating
2002-12-10 12:30 ` Eric Botcazou
2 siblings, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2002-10-25 13:57 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
On Wed, Oct 16, 2002 at 08:24:14PM +0200, Jan Hubicka wrote:
> * toplev.c (dump_file_index): Add DFI_ce3.
> (dump_file_info): Likewise.
> (rest_of_compilation): Run first ifcvt pass before tracer.
What you're looking for is a run of ifcvt _with_ life data.
I don't think you're going to get what you want without that.
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 13:57 ` Richard Henderson
@ 2002-10-25 14:07 ` Jan Hubicka
2002-10-25 14:10 ` Richard Henderson
0 siblings, 1 reply; 19+ messages in thread
From: Jan Hubicka @ 2002-10-25 14:07 UTC (permalink / raw)
To: Richard Henderson, Jan Hubicka, gcc-patches
> On Wed, Oct 16, 2002 at 08:24:14PM +0200, Jan Hubicka wrote:
> > * toplev.c (dump_file_index): Add DFI_ce3.
> > (dump_file_info): Likewise.
> > (rest_of_compilation): Run first ifcvt pass before tracer.
>
> What you're looking for is a run of ifcvt _with_ life data.
> I don't think you're going to get what you want without that.
Yes, there is still much less ifcvt than I would wish. On cfg branch we
did early liveness pass and I've been asking about it for mainline too
before the freeze. I think it makes sense - we can use it for GCSE code
hoisting with clobbers, for better dead code removal and for better
ifcvt before tracing, but that is something I would like to handle
separately from this simple patch.
Honza
>
>
> r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 14:07 ` Jan Hubicka
@ 2002-10-25 14:10 ` Richard Henderson
2002-10-25 14:12 ` Jan Hubicka
0 siblings, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2002-10-25 14:10 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
> ... but that is something I would like to handle
> separately from this simple patch.
So what does this accomplish that the call during cse2 does not?
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 14:10 ` Richard Henderson
@ 2002-10-25 14:12 ` Jan Hubicka
2002-10-25 14:19 ` Richard Henderson
0 siblings, 1 reply; 19+ messages in thread
From: Jan Hubicka @ 2002-10-25 14:12 UTC (permalink / raw)
To: Richard Henderson, Jan Hubicka, gcc-patches
> > ... but that is something I would like to handle
> > separately from this simple patch.
>
> So what does this accomplish that the call during cse2 does not?
The ifcvt pass even without liveness does quite a lot, but once tracing
is done it does almost nothing. So by reordering ifcvt before cse2 and
tracer results in quite a bit better code (that can be futher improved
if liveness were available before first ifcvt pass)
Honza
>
>
> r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 14:12 ` Jan Hubicka
@ 2002-10-25 14:19 ` Richard Henderson
2002-10-25 14:27 ` Jan Hubicka
0 siblings, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2002-10-25 14:19 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
On Fri, Oct 25, 2002 at 11:12:43PM +0200, Jan Hubicka wrote:
> > So what does this accomplish that the call during cse2 does not?
>
> The ifcvt pass even without liveness does quite a lot, but once tracing
> is done it does almost nothing. So by reordering ifcvt before cse2 and
> tracer results in quite a bit better code (that can be futher improved
> if liveness were available before first ifcvt pass)
This doesn't answer my question. The tracer runs after cse2,
correct? The current non-life ifcvt pass runs after cse2 and
before the tracer, correct?
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 14:19 ` Richard Henderson
@ 2002-10-25 14:27 ` Jan Hubicka
2002-10-25 15:02 ` Richard Henderson
0 siblings, 1 reply; 19+ messages in thread
From: Jan Hubicka @ 2002-10-25 14:27 UTC (permalink / raw)
To: Richard Henderson, Jan Hubicka, gcc-patches
> On Fri, Oct 25, 2002 at 11:12:43PM +0200, Jan Hubicka wrote:
> > > So what does this accomplish that the call during cse2 does not?
> >
> > The ifcvt pass even without liveness does quite a lot, but once tracing
> > is done it does almost nothing. So by reordering ifcvt before cse2 and
> > tracer results in quite a bit better code (that can be futher improved
> > if liveness were available before first ifcvt pass)
>
> This doesn't answer my question. The tracer runs after cse2,
> correct? The current non-life ifcvt pass runs after cse2 and
No, it runs before cse2, so current ifcvt runs only after tracer before
Roger has removed the other invokations.
Honza
> before the tracer, correct?
>
>
>
> r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 14:27 ` Jan Hubicka
@ 2002-10-25 15:02 ` Richard Henderson
2002-10-26 10:27 ` Graham Stott
0 siblings, 1 reply; 19+ messages in thread
From: Richard Henderson @ 2002-10-25 15:02 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
On Fri, Oct 25, 2002 at 11:26:56PM +0200, Jan Hubicka wrote:
> No, it runs before cse2, so current ifcvt runs only after tracer before
> Roger has removed the other invokations.
Oh. I mis-read your patch then.
Yeah, this is ok for mainline.
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-25 15:02 ` Richard Henderson
@ 2002-10-26 10:27 ` Graham Stott
0 siblings, 0 replies; 19+ messages in thread
From: Graham Stott @ 2002-10-26 10:27 UTC (permalink / raw)
To: Richard Henderson; +Cc: Jan Hubicka, gcc-patches
Richard Henderson wrote:
> On Fri, Oct 25, 2002 at 11:26:56PM +0200, Jan Hubicka wrote:
>
>>No, it runs before cse2, so current ifcvt runs only after tracer before
>>Roger has removed the other invokations.
>
>
> Oh. I mis-read your patch then.
>
> Yeah, this is ok for mainline.
>
>
> r~
>
Alas this breaks bootstraps with Ada on i686-pc-linux-gnu.
See messages in the "Ada bootstrap fails on CVS mainline" thread
on the gcc@gcc.gnu.org mailing list.
Graham
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-16 11:24 ifcvt pass ordering Jan Hubicka
2002-10-25 13:57 ` Richard Henderson
@ 2002-10-26 14:57 ` Geoff Keating
2002-10-26 15:02 ` Jan Hubicka
2002-10-26 15:25 ` Fix for " Jan Hubicka
2002-12-10 12:30 ` Eric Botcazou
2 siblings, 2 replies; 19+ messages in thread
From: Geoff Keating @ 2002-10-26 14:57 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches, gcc-regression
Jan Hubicka <jh@suse.cz> writes:
> Hi,
> Robert's patch to disable early ifcvt passes had unwanted effect of
> disabling almost all ifcvt with -ftracer. -ftracer usually duplicates
> code to make ifcvt impossible so we must run at least one pass before.
> I would like to see this in the mainline too, but technically it is not
> regression, so I would be happy with BIB branch too.
>
> Wed Oct 16 20:23:12 CEST 2002 Jan Hubicka <jh@suse.cz>
> * toplev.c (dump_file_index): Add DFI_ce3.
> (dump_file_info): Likewise.
> (rest_of_compilation): Run first ifcvt pass before tracer.
This also causes a bunch of regressions on Darwin; at least, it's all
the following:
native gcc.sum gcc.c-torture/compile/20000802-1.c,
native gcc.sum gcc.c-torture/compile/20020604-1.c,
native gcc.sum gcc.c-torture/compile/900407-1.c,
native gcc.sum gcc.c-torture/compile/920501-4.c,
native gcc.sum gcc.c-torture/compile/921011-1.c,
native gcc.sum gcc.c-torture/compile/921013-1.c,
native gcc.sum gcc.c-torture/compile/921206-1.c,
native gcc.sum gcc.c-torture/compile/930523-1.c,
native gcc.sum gcc.c-torture/compile/980329-1.c,
native gcc.sum gcc.c-torture/compile/980506-2.c,
native gcc.sum gcc.c-torture/execute/20000412-4.c
native gcc.sum gcc.c-torture/execute/20000503-1.c
native gcc.sum gcc.c-torture/execute/20000511-1.c
native gcc.sum gcc.c-torture/execute/20020406-1.c
native gcc.sum gcc.c-torture/execute/20020716-1.c
native gcc.sum gcc.c-torture/execute/930123-1.c
native gcc.sum gcc.c-torture/execute/931012-1.c
The symptom is (this is for 980506-2.c at -O1):
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000e4e1c in init_alias_analysis () at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/alias.c:2814
2814 else if (REG_N_SETS (regno) == 1
(gdb) bt
#0 0x000e4e1c in init_alias_analysis () at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/alias.c:2814
#1 0x0019328c in life_analysis (f=0xe1a480, file=0x0, flags=383) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/flow.c:452
#2 0x00099670 in rest_of_compilation (decl=0x17f) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/toplev.c:3061
#3 0x0002295c in c_expand_body (fndecl=0xe49150, nested_p=671089216, can_defer_p=3454324) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/c-decl.c:6519
#4 0x000224ec in finish_function (nested=0, can_defer_p=1) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/c-decl.c:6390
#5 0x00002b18 in yyparse () at c-parse.y:403
#6 0x000106c0 in c_common_parse_file (set_yydebug=173) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/c-lex.c:159
#7 0x000985d4 in compile_file () at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/toplev.c:2121
#8 0x0009dad0 in do_compile () at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/toplev.c:5334
#9 0x0009db9c in toplev_main (argc=23, argv=0xbffffa80) at /Network/Servers/cauchy/homes/thorin/gkeating/co/egcs-mainline/gcc/gcc/toplev.c:5364
#10 0x00001920 in _start (argc=23, argv=0xbffffa80, envp=0xbffffae0) at /SourceCache/Csu/Csu-45/crt.c:267
#11 0x000017a0 in start ()
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-26 14:57 ` Geoff Keating
@ 2002-10-26 15:02 ` Jan Hubicka
2002-10-26 15:25 ` Fix for " Jan Hubicka
1 sibling, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2002-10-26 15:02 UTC (permalink / raw)
To: Geoff Keating; +Cc: Jan Hubicka, gcc-patches, gcc-regression
> Jan Hubicka <jh@suse.cz> writes:
>
> > Hi,
> > Robert's patch to disable early ifcvt passes had unwanted effect of
> > disabling almost all ifcvt with -ftracer. -ftracer usually duplicates
> > code to make ifcvt impossible so we must run at least one pass before.
> > I would like to see this in the mainline too, but technically it is not
> > regression, so I would be happy with BIB branch too.
> >
> > Wed Oct 16 20:23:12 CEST 2002 Jan Hubicka <jh@suse.cz>
> > * toplev.c (dump_file_index): Add DFI_ce3.
> > (dump_file_info): Likewise.
> > (rest_of_compilation): Run first ifcvt pass before tracer.
>
> This also causes a bunch of regressions on Darwin; at least, it's all
> the following:
I am just looking into it. I guess regscan pass got lost somewhere,
that is curious since I am quite sure I was moving it before ifcvt.
Let me check.
Honza
^ permalink raw reply [flat|nested] 19+ messages in thread
* Fix for ifcvt pass ordering
2002-10-26 14:57 ` Geoff Keating
2002-10-26 15:02 ` Jan Hubicka
@ 2002-10-26 15:25 ` Jan Hubicka
2002-10-29 6:30 ` Richard Henderson
1 sibling, 1 reply; 19+ messages in thread
From: Jan Hubicka @ 2002-10-26 15:25 UTC (permalink / raw)
To: Geoff Keating; +Cc: Jan Hubicka, gcc-patches, gcc-regression, rth
> Jan Hubicka <jh@suse.cz> writes:
>
> > Hi,
> > Robert's patch to disable early ifcvt passes had unwanted effect of
> > disabling almost all ifcvt with -ftracer. -ftracer usually duplicates
> > code to make ifcvt impossible so we must run at least one pass before.
> > I would like to see this in the mainline too, but technically it is not
> > regression, so I would be happy with BIB branch too.
> >
> > Wed Oct 16 20:23:12 CEST 2002 Jan Hubicka <jh@suse.cz>
> > * toplev.c (dump_file_index): Add DFI_ce3.
> > (dump_file_info): Likewise.
> > (rest_of_compilation): Run first ifcvt pass before tracer.
>
> This also causes a bunch of regressions on Darwin; at least, it's all
> the following:
>
> native gcc.sum gcc.c-torture/compile/20000802-1.c,
> native gcc.sum gcc.c-torture/compile/20020604-1.c,
> native gcc.sum gcc.c-torture/compile/900407-1.c,
> native gcc.sum gcc.c-torture/compile/920501-4.c,
> native gcc.sum gcc.c-torture/compile/921011-1.c,
> native gcc.sum gcc.c-torture/compile/921013-1.c,
> native gcc.sum gcc.c-torture/compile/921206-1.c,
> native gcc.sum gcc.c-torture/compile/930523-1.c,
> native gcc.sum gcc.c-torture/compile/980329-1.c,
> native gcc.sum gcc.c-torture/compile/980506-2.c,
> native gcc.sum gcc.c-torture/execute/20000412-4.c
> native gcc.sum gcc.c-torture/execute/20000503-1.c
> native gcc.sum gcc.c-torture/execute/20000511-1.c
> native gcc.sum gcc.c-torture/execute/20020406-1.c
> native gcc.sum gcc.c-torture/execute/20020716-1.c
> native gcc.sum gcc.c-torture/execute/930123-1.c
> native gcc.sum gcc.c-torture/execute/931012-1.c
Hi,
the problem has been uncovered latent bug - we didn't run reg-scan pass in all
ocasions when cse2 has been disabled but used the info in final pass by
enabling alias analysis. I am just testing the attached patch that makes the
ifcvt1 pass to finish with reg_scan data valid and all the subsequent passes to
update it as needed.
I've verified it to test the testcase, bootstrap in progress. OK if it passes?
I apologize for the breakage. Since I didn't expected the patch to
change something I must've missed the failures somehow.
Honza
Sun Oct 27 00:20:08 CEST 2002 Jan Hubicka <jh@suse.cz>
* toplev.c (rest_of_compilation): Reorganize way reg_scan is called
before final pass.
Index: toplev.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/toplev.c,v
retrieving revision 1.684
diff -c -3 -p -r1.684 toplev.c
*** toplev.c 25 Oct 2002 23:46:06 -0000 1.684
--- toplev.c 26 Oct 2002 22:19:53 -0000
*************** rest_of_compilation (decl)
*** 2987,3003 ****
close_dump_file (DFI_bp, print_rtl_with_bb, insns);
timevar_pop (TV_BRANCH_PROB);
}
! if (flag_if_conversion)
{
- timevar_push (TV_IFCVT);
- if (rtl_dump_file)
- dump_flow_info (rtl_dump_file);
open_dump_file (DFI_ce1, decl);
cleanup_cfg (CLEANUP_EXPENSIVE);
reg_scan (insns, max_reg_num (), 0);
! if_convert (0);
close_dump_file (DFI_ce1, print_rtl_with_bb, get_insns ());
- timevar_pop (TV_IFCVT);
}
if (flag_tracer)
{
--- 2987,3010 ----
close_dump_file (DFI_bp, print_rtl_with_bb, insns);
timevar_pop (TV_BRANCH_PROB);
}
! if (optimize >= 0)
{
open_dump_file (DFI_ce1, decl);
+ if (flag_if_conversion)
+ {
+ timevar_push (TV_IFCVT);
+ if (rtl_dump_file)
+ dump_flow_info (rtl_dump_file);
+ cleanup_cfg (CLEANUP_EXPENSIVE);
+ reg_scan (insns, max_reg_num (), 0);
+ if_convert (0);
+ timevar_pop (TV_IFCVT);
+ }
+ timevar_push (TV_JUMP);
cleanup_cfg (CLEANUP_EXPENSIVE);
reg_scan (insns, max_reg_num (), 0);
! timevar_pop (TV_JUMP);
close_dump_file (DFI_ce1, print_rtl_with_bb, get_insns ());
}
if (flag_tracer)
{
*************** rest_of_compilation (decl)
*** 3005,3051 ****
open_dump_file (DFI_tracer, decl);
if (rtl_dump_file)
dump_flow_info (rtl_dump_file);
- cleanup_cfg (CLEANUP_EXPENSIVE);
tracer ();
cleanup_cfg (CLEANUP_EXPENSIVE);
close_dump_file (DFI_tracer, print_rtl_with_bb, get_insns ());
timevar_pop (TV_TRACER);
- reg_scan (get_insns (), max_reg_num (), 0);
}
! if (optimize > 0)
{
timevar_push (TV_CSE2);
open_dump_file (DFI_cse2, decl);
if (rtl_dump_file)
dump_flow_info (rtl_dump_file);
! if (flag_rerun_cse_after_loop)
{
timevar_push (TV_JUMP);
! reg_scan (insns, max_reg_num (), 0);
! timevar_pop (TV_JUMP);
!
cleanup_cfg (CLEANUP_EXPENSIVE);
! /* CFG is no longer maintained up-to-date. */
! reg_scan (insns, max_reg_num (), 0);
! tem = cse_main (insns, max_reg_num (), 1, rtl_dump_file);
! purge_all_dead_edges (0);
! delete_trivially_dead_insns (insns, max_reg_num ());
!
! if (tem)
! {
! timevar_push (TV_JUMP);
! rebuild_jump_labels (insns);
! cleanup_cfg (CLEANUP_EXPENSIVE);
! timevar_pop (TV_JUMP);
! }
}
!
close_dump_file (DFI_cse2, print_rtl_with_bb, insns);
- timevar_pop (TV_CSE2);
-
ggc_collect ();
}
cse_not_expected = 1;
--- 3012,3046 ----
open_dump_file (DFI_tracer, decl);
if (rtl_dump_file)
dump_flow_info (rtl_dump_file);
tracer ();
cleanup_cfg (CLEANUP_EXPENSIVE);
+ reg_scan (insns, max_reg_num (), 0);
close_dump_file (DFI_tracer, print_rtl_with_bb, get_insns ());
timevar_pop (TV_TRACER);
}
! if (flag_rerun_cse_after_loop)
{
timevar_push (TV_CSE2);
open_dump_file (DFI_cse2, decl);
if (rtl_dump_file)
dump_flow_info (rtl_dump_file);
+ /* CFG is no longer maintained up-to-date. */
+ tem = cse_main (insns, max_reg_num (), 1, rtl_dump_file);
+ purge_all_dead_edges (0);
+ delete_trivially_dead_insns (insns, max_reg_num ());
! if (tem)
{
timevar_push (TV_JUMP);
! rebuild_jump_labels (insns);
cleanup_cfg (CLEANUP_EXPENSIVE);
! timevar_pop (TV_JUMP);
}
! reg_scan (insns, max_reg_num (), 0);
close_dump_file (DFI_cse2, print_rtl_with_bb, insns);
ggc_collect ();
+ timevar_pop (TV_CSE2);
}
cse_not_expected = 1;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Fix for ifcvt pass ordering
2002-10-26 15:25 ` Fix for " Jan Hubicka
@ 2002-10-29 6:30 ` Richard Henderson
0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2002-10-29 6:30 UTC (permalink / raw)
To: Jan Hubicka; +Cc: Geoff Keating, gcc-patches, gcc-regression
On Sun, Oct 27, 2002 at 12:24:57AM +0200, Jan Hubicka wrote:
> * toplev.c (rest_of_compilation): Reorganize way reg_scan is called
> before final pass.
Ok.
r~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-10-16 11:24 ifcvt pass ordering Jan Hubicka
2002-10-25 13:57 ` Richard Henderson
2002-10-26 14:57 ` Geoff Keating
@ 2002-12-10 12:30 ` Eric Botcazou
2 siblings, 0 replies; 19+ messages in thread
From: Eric Botcazou @ 2002-12-10 12:30 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
> Wed Oct 16 20:23:12 CEST 2002 Jan Hubicka <jh@suse.cz>
> * toplev.c (dump_file_index): Add DFI_ce3.
> (dump_file_info): Likewise.
> (rest_of_compilation): Run first ifcvt pass before tracer.
As the reporter of PR optimization/8848 says, it would be nice if you updated
the docs accordingly, i.e mentioned the new pass and shifted the pass index
numbers.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-11-02 19:52 John David Anglin
2002-11-03 3:30 ` Jan Hubicka
@ 2003-03-06 16:05 ` Jan Hubicka
1 sibling, 0 replies; 19+ messages in thread
From: Jan Hubicka @ 2003-03-06 16:05 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc-patches, jh
> I have dtermined by elimination that the ifcvt pass reordering
>
> Sat Oct 26 01:44:46 CEST 2002 Jan Hubicka <jh@suse.cz>
>
> * toplev.c (dump_file_index): Add DFI_ce3.
> (dump_file_info): Likewise.
> (rest_of_compilation): Run first ifcvt pass before tracer.
>
> results in the failure of g77.f-torture/execute/970625-2.f on the PA
> (hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11* and hppa64-hp-hpux11*).
I tought Richard has already sent a patch for this preventing ifcvt from
taking action when the register is CC mode.
What happent to it? I will try to dig into it tonight or tomorrow.
Honza
>
> The following error occurs:
>
> /home/dave/gcc-3.3/gcc/gcc/testsuite/g77.f-torture/execute/970625-2.f:74: internal compiler error: in convert_move, at expr.c:1303
>
> We have
> Breakpoint 1, convert_move (to=0x401ba240, from=0x401ba270, unsignedp=0)
> at ../../gcc/gcc/expr.c:1303
> 1303 abort ();
> (gdb) p debug_rtx (to)
> (reg:CCFP 142)
> $1 = void
> (gdb) p debug_rtx (from)
> (reg:SI 143)
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-11-03 3:30 ` Jan Hubicka
2002-11-03 9:38 ` John David Anglin
@ 2003-01-15 22:44 ` John David Anglin
1 sibling, 0 replies; 19+ messages in thread
From: John David Anglin @ 2003-01-15 22:44 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches, jh
> > I have dtermined by elimination that the ifcvt pass reordering
> >
> > Sat Oct 26 01:44:46 CEST 2002 Jan Hubicka <jh@suse.cz>
> >
> > * toplev.c (dump_file_index): Add DFI_ce3.
> > (dump_file_info): Likewise.
> > (rest_of_compilation): Run first ifcvt pass before tracer.
> >
> > results in the failure of g77.f-torture/execute/970625-2.f on the PA
> > (hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11* and hppa64-hp-hpux11*).
> >
> > The following error occurs:
> >
> > /home/dave/gcc-3.3/gcc/gcc/testsuite/g77.f-torture/execute/970625-2.f:74: internal compiler error: in convert_move, at expr.c:1303
> >
> > We have
> > Breakpoint 1, convert_move (to=0x401ba240, from=0x401ba270, unsignedp=0)
> > at ../../gcc/gcc/expr.c:1303
> > 1303 abort ();
> > (gdb) p debug_rtx (to)
> > (reg:CCFP 142)
> > $1 = void
> > (gdb) p debug_rtx (from)
> > (reg:SI 143)
> Interesting.
> This looks like latent PA bug uncovered, but I will try to check it next
> week.
I have hit this bug in a g++ compilation of octave-2.1.43 as well as
in the g77 test above. You imply that there should be a pattern to
handle this conversion. There exists no direct hardware instruction
to perform the conversion. Normally, CCFP is only set by floating
point comparison operations but there are two patterns which directly
set the values 0 and 1 from the constants 0 and 1. These patterns
were added at the suggestion of Roger Sayle to improve code optimization.
If we now are required to have a method to directly set reg:CCFP from
a register, what is the proper way? Set it to 0 when the register is
0 and otherwise set it to 1? Or, should it be set from the lsb of the
register? I am skeptical that either should actually be needed.
In order to set reg:CCFP, I would need to test the register in some
way, and then execute one of two possible floating point comparisons
using register %fr0 which is hardwired to +0.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-11-03 3:30 ` Jan Hubicka
@ 2002-11-03 9:38 ` John David Anglin
2003-01-15 22:44 ` John David Anglin
1 sibling, 0 replies; 19+ messages in thread
From: John David Anglin @ 2002-11-03 9:38 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches, jh
> > Breakpoint 1, convert_move (to=0x401ba240, from=0x401ba270, unsignedp=0)
> > at ../../gcc/gcc/expr.c:1303
> > 1303 abort ();
> > (gdb) p debug_rtx (to)
> > (reg:CCFP 142)
> > $1 = void
> > (gdb) p debug_rtx (from)
> > (reg:SI 143)
> Interesting.
> This looks like latent PA bug uncovered, but I will try to check it next
> week.
Possibly. It looks as if ifcvt is trying to set reg:CCFP directly from
a register. This is not possible on the PA. The only direct sets are
for the const_int's 0 and 1. Everything else involves compares.
The backtrace involves a fair number of routines in ifcvt.c which I know
next to nothing about. So, it would be be a big help if you could check
on this problem.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
2002-11-02 19:52 John David Anglin
@ 2002-11-03 3:30 ` Jan Hubicka
2002-11-03 9:38 ` John David Anglin
2003-01-15 22:44 ` John David Anglin
2003-03-06 16:05 ` Jan Hubicka
1 sibling, 2 replies; 19+ messages in thread
From: Jan Hubicka @ 2002-11-03 3:30 UTC (permalink / raw)
To: John David Anglin; +Cc: gcc-patches, jh
> I have dtermined by elimination that the ifcvt pass reordering
>
> Sat Oct 26 01:44:46 CEST 2002 Jan Hubicka <jh@suse.cz>
>
> * toplev.c (dump_file_index): Add DFI_ce3.
> (dump_file_info): Likewise.
> (rest_of_compilation): Run first ifcvt pass before tracer.
>
> results in the failure of g77.f-torture/execute/970625-2.f on the PA
> (hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11* and hppa64-hp-hpux11*).
>
> The following error occurs:
>
> /home/dave/gcc-3.3/gcc/gcc/testsuite/g77.f-torture/execute/970625-2.f:74: internal compiler error: in convert_move, at expr.c:1303
>
> We have
> Breakpoint 1, convert_move (to=0x401ba240, from=0x401ba270, unsignedp=0)
> at ../../gcc/gcc/expr.c:1303
> 1303 abort ();
> (gdb) p debug_rtx (to)
> (reg:CCFP 142)
> $1 = void
> (gdb) p debug_rtx (from)
> (reg:SI 143)
Interesting.
This looks like latent PA bug uncovered, but I will try to check it next
week.
Honza
>
> Dave
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: ifcvt pass ordering
@ 2002-11-02 19:52 John David Anglin
2002-11-03 3:30 ` Jan Hubicka
2003-03-06 16:05 ` Jan Hubicka
0 siblings, 2 replies; 19+ messages in thread
From: John David Anglin @ 2002-11-02 19:52 UTC (permalink / raw)
To: gcc-patches, jh
I have dtermined by elimination that the ifcvt pass reordering
Sat Oct 26 01:44:46 CEST 2002 Jan Hubicka <jh@suse.cz>
* toplev.c (dump_file_index): Add DFI_ce3.
(dump_file_info): Likewise.
(rest_of_compilation): Run first ifcvt pass before tracer.
results in the failure of g77.f-torture/execute/970625-2.f on the PA
(hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11* and hppa64-hp-hpux11*).
The following error occurs:
/home/dave/gcc-3.3/gcc/gcc/testsuite/g77.f-torture/execute/970625-2.f:74: internal compiler error: in convert_move, at expr.c:1303
We have
Breakpoint 1, convert_move (to=0x401ba240, from=0x401ba270, unsignedp=0)
at ../../gcc/gcc/expr.c:1303
1303 abort ();
(gdb) p debug_rtx (to)
(reg:CCFP 142)
$1 = void
(gdb) p debug_rtx (from)
(reg:SI 143)
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2003-03-06 16:05 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-16 11:24 ifcvt pass ordering Jan Hubicka
2002-10-25 13:57 ` Richard Henderson
2002-10-25 14:07 ` Jan Hubicka
2002-10-25 14:10 ` Richard Henderson
2002-10-25 14:12 ` Jan Hubicka
2002-10-25 14:19 ` Richard Henderson
2002-10-25 14:27 ` Jan Hubicka
2002-10-25 15:02 ` Richard Henderson
2002-10-26 10:27 ` Graham Stott
2002-10-26 14:57 ` Geoff Keating
2002-10-26 15:02 ` Jan Hubicka
2002-10-26 15:25 ` Fix for " Jan Hubicka
2002-10-29 6:30 ` Richard Henderson
2002-12-10 12:30 ` Eric Botcazou
2002-11-02 19:52 John David Anglin
2002-11-03 3:30 ` Jan Hubicka
2002-11-03 9:38 ` John David Anglin
2003-01-15 22:44 ` John David Anglin
2003-03-06 16:05 ` Jan Hubicka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).