optimization/1945

[Shane Nay]

The following reply was made to PR optimization/1945; it has been noted by GNATS.

From: Shane Nay <shane@agendacomputing.com>
To: rth@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
	shane@agendacomputing.com
Cc:  
Subject: Re: optimization/1945
Date: Tue, 13 Feb 2001 00:37:26 -0800

 >     Neither of these patches will be applied, as both are incorrect.
 
 Yes, wasn't asking for them to be applied, more for others that are 
 experiencing the same problem.  It has been going on since December I think.  
 It's painfull for linux-ce folk because we're using an old egcs release, but 
 we can't bring forward our kernel with it.  We can bring forward our kernel 
 with last egcs release, but then it won't build glibc.  2.95.2 also has some 
 sort of ugly bug, so our only out is either back porting stuff to 2.95.2, or 
 using gcc-CVS until 3.0 is out.
 
 >     Your long-term option 2 is the only acceptable solution.
 >     I did not acree with the addition of REG_MAYBE_DEAD in
 >     the first place and don't want to see it used unless
 >     absolutely positively necessary.
 
 Yes, it seems silly to me, but I'm not a compiler hacker, so...  Especially 
 given that it's not used anywhere.  Not only that, but when you generate the 
 prologue, you've already done all your dead scans, so you already know what's 
 not going to be used..., so why is RTL being generated to set registers that 
 are not being used in any of the insns?  I don't know..., but I guess I 
 should find out.
 
 So then, where do you think it should be done?, at the end of the 
 epilogue/prologue generation code (for insn=prologue_end;insn;insn=prev { 
 is_this_a_bogus_register_manipulation(insn) rip_it_out(insn)} ), or something 
 added to cleanup_cfg in the case of after reload?
 
 Thanks,
 Shane Nay.