This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Repost: RFA: re-instate struct_equiv code
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: Joern RENNECKE <joern dot rennecke at st dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org, zadeck at naturalbridge dot com
- Date: Tue, 31 Jan 2006 19:48:53 -0500
- Subject: Re: Repost: RFA: re-instate struct_equiv code
- References: <200512150048.50502.stevenb@suse.de> <1134615284.9942.101.camel@linux.site> <43A2BCEE.3090508@t-online.de> <43BD984A.7090504@st.com> <43BD9945.2080302@st.com> <43BD9B60.6000208@st.com> <43CB9D09.4070205@st.com> <43D79D38.6060109@st.com> <43DE3923.9080905@t-online.de> <43E000A7.7010403@t-online.de>
Bernd Schmidt wrote:
> Bernd Schmidt wrote:
>> What we must do is ensure that we can rely on life information in
>> struct_equiv_init by making all transformations done during
>> try_optimize_cfg keep register life information intact. This seems to
>> be true for things like merge_blocks etc.
>
> I found one that doesn't. Replacing condjumps with unconditional jumps
> with try_redirect_by_replacing_jump can kill flag registers.
>
I still think the idea above is a losing proposition.
Your choices are
1. Make it quite slow in some cases because each life update can change
liveness in a large number of blocks. (This is just a fact of liveness)
2. Make the liveness information "fast" but imprecise.
Neither of these is a good option.
Why doesn't the struct-equiv code run a single time in a separate pass
or something, instead of inserting stuff into cleanup_cfg?
I highly doubt it needs to be run 50 or 60 times.
--Dan