Repost: RFA [4.1]: improvement to if-conversion and cross-jumping (PR20070)

Joern RENNECKE joern.rennecke@st.com
Mon Dec 12 18:58:00 GMT 2005


Bernd Schmidt wrote:

>  
> This code appears twice.  Please split out into a function. 

While doing that, I also found that the second site was missing 
processing of info->common_live.

>  
> This doesn't do anything different from the normal recursive bit at 
> the end of the function, does it?  If it isn't needed, delete this part.

It does something different - it first processes set destinations, and 
then sources.  That is the right thing to do if rvalue == 1.
However, AFAICS there is no caller left which can cause rvalue == 1 when 
we are processing a PARALLEL.   Instead, it will
always be -1, which is  correctly  handled by the default processing.  
Therefore, I have replaced this code with a gcc_assert and a
break; .

>  
> Are they really all dead at the end of each block?  It's been a long 
> time since I looked at reg-stack, but this looks odd to me.

No, they are not all dead.  But we don't have any up-to-date information 
on these registers, because reg-stack changes the actual register 
numbers used, but it doesn't update the global_live_at{start,end}.  And 
update_live_info lacks the smarts to  do a  proper update.  (The 
bogosity of the live info is taken care of by not changing register 
usage by stack regs after reg-stack.)  Since we  are changing some 
blocks by cross-jumping, we end up with live information on the stack 
regs that is not only bogus, but also inconsistent between different 
blocks with identical successors.  I have amended the comment to make it 
clear that this is not about generating correct information, but merely 
consistent information.

I have attached the updated patch that takes your comments into 
account.  regtesting is underway.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cmove-diff-20051212-1819-1
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20051212/f4483b23/attachment.ksh>


More information about the Gcc-patches mailing list