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