This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Take 3: RFA: re-instate struct_equiv code
- From: Joern RENNECKE <joern dot rennecke at st dot com>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 Mar 2006 16:17:13 +0000
- Subject: Re: Take 3: RFA: re-instate struct_equiv code
- References: <43EA0A69.6030007@st.com> <43F67B2C.2000109@t-online.de> <43F9C956.7070701@st.com> <43F9F957.9060308@t-online.de> <43FA0354.7040902@st.com> <43FA38DC.6020306@t-online.de>
Bernd Schmidt wrote:
Joern RENNECKE wrote:
Bernd Schmidt wrote:
Downsides to this:
- it's harder to understand exactly which inconsistencies are ok
rather than disallowing them
You can't disallow them without doing complete data flow
recomputations (not just updates) all the time.
[...]
Note that we don't check for the inconsistencies that remain - i.e.
registers that are actually dead but are marked
live - this inexact data flow information will be (or at least should be
by design) self-consistent after
update_life_info_in_dirty_blocks.
The way you re-arranged the code, we could still see spurious
mismatches.
Code path?
I re-examined the code, and I think I probably was mistaken.
As far as I can tell, your code is a bit slower than necessary in order
to be able to perform
extra sanity checks, but it should eventually find all available
cross-jump opportunities -
unless some freak optimization ordering issue gets in the way.