This is the mail archive of the gcc-bugs@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: i386-linux cross sh-elf breakage


On Tue, May 16, 2000 at 05:58:51PM -0700, Richard Henderson wrote:
> On Tue, May 16, 2000 at 02:01:46PM -0500, Clinton Popetz wrote:
> 
> > Richard, should recompute_reg_usage use UPDATE_LIFE_GLOBAL, or should we
> > call update_life_info after optimize_mode_switching?
> 
> That said, optimize_mode_switching may very well need to redo
> global life info anyway.  We may want to tweek when no_new_pseudos
> gets set in that case too, so that we don't overwork wrt 
> recompute_reg_usage.

Hmm.  When we call optimize_mode_switching, we don't know if it's going to do
anything (and it won't, except for the sh.)  So it seemed to me that I should
put the call to update_life_info in optimize_mode_switching, so that we don't
do extra work unless it's needed.

Is it ok to also set no_new_pseudos there, and to have recompute_reg_usage
check this to determine how much work to do (or is there a flag to indicate
"life info is up to date"?)  The reason I ask is that scheduling hasn't run
yet, and although flag_schedule_insns is always off for the sh, that might not
be true for future uses of optimize_mode_switching.  Having
optimize_mode_switching set no_new_pseudos iff flag_schedule_insns is false
seems like a bad idea, because it puts knowledge of how the passes are ordered
into lcm.c.

I suppose I could move the #ifdef OPTIMIZE_MODE_SWITCHING up into toplev.c, so
that we know whether that pass will do work.  That seems to be the convention
anyway.

				-Clint

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