Bug 16585 - current_function_has_computed_jump incorrectly changed in make_edges
Summary: current_function_has_computed_jump incorrectly changed in make_edges
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Steven Bosscher
URL:
Keywords: missed-optimization
Depends on:
Blocks: 15242
  Show dependency treegraph
 
Reported: 2004-07-16 06:50 UTC by Josef Zlomek
Modified: 2005-01-26 17:27 UTC (History)
1 user (show)

See Also:
Host: i386-unknown-linux
Target: i386-unknown-linux
Build: i386-unknown-linux
Known to work:
Known to fail:
Last reconfirmed: 2004-10-25 16:34:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Josef Zlomek 2004-07-16 06:50:17 UTC
make_edges() clears current_function_has_computed_jump flag in its beginning
and set it only if it finds a computed jump in a *range* of basic blocks which
is passed in its arguments.

So the result is that the flag is incorrectly cleared when a range of blocks
which does not contain the computed jump although the current function contains
the computed jump is passed to make_edges().

This behaviour occurs when compiling the testcase "ef.i" from PR/15242 with "-O2".
Comment 1 Andrew Pinski 2004-07-16 07:10:08 UTC
The only function which calls make_edges which should not is find_many_sub_basic_blocks which gets 
called from cfgexpand with all ones which is fine and commit_edge_insertions and 
commit_edge_insertions_watch_calls (and maybe split_all_insns) which is where the problem comes 
into play I think.  The only functions besides your patch which uses this flag is is_cfg_nonregular which 
is used for scheduling.
Comment 2 Andrew Pinski 2004-10-25 16:31:38 UTC
Confirmed.
Comment 3 Steven Bosscher 2004-10-25 16:34:03 UTC
I think the brute-force approach of just updating 
current_function_has_computed_jump in a FOR_EACH_BB loop 
after calling make_edges is a "good enough" fix for this 
problem.  We can figure out if we have computed jumps at 
the tree level and keep it updated from there on. 
 
I'm testing a patch to do exactly this. 
 
 
Comment 4 Andrew Pinski 2005-01-24 00:56:54 UTC
Assigning to Steven since he had accepted it before (just unassign if you don't want this bug anymore).
Comment 5 Steven Bosscher 2005-01-26 15:16:52 UTC
We can just zap it completely, of course: 
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01892.html 
Comment 6 GCC Commits 2005-01-26 17:26:56 UTC
Subject: Bug 16585

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	steven@gcc.gnu.org	2005-01-26 17:26:36

Modified files:
	gcc            : ChangeLog cfgbuild.c function.h sched-rgn.c 

Log message:
	PR middle-end/16585
	* cfgbuild.c (make_edges): Do not clear or set
	current_function_has_computed_jump.
	* function.h (struct function): Remove the has_computed_jump field.
	(current_function_has_computed_jump): Do not define.
	* sched-rgn.c (is_cfg_nonregular): Return true if a basic block ends
	in a computed jump.  Ignore current_function_has_computed_jump.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7286&r2=2.7287
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgbuild.c.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.h.diff?cvsroot=gcc&r1=1.137&r2=1.138
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/sched-rgn.c.diff?cvsroot=gcc&r1=1.91&r2=1.92

Comment 7 Steven Bosscher 2005-01-26 17:27:58 UTC
zap.