This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.3.0 Status Report (2007-08-09)


> Jan Hubicka wrote:
> 
> > One thing I would like to see in is the sharing checker.  The criteria
> > of bootstrap/regtesting on primary platforms is almost met now with
> > exception of regmove pass that I sent patch for some time ago.
> > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01441.html
> > I will do re-testing now and see if some new problems has appeared.
> 
> Thank you for bringing this up.  I'd let to get the checker in too.
> But, I don't really understand the regrename.c patch.  Are you saying
> that regrename.c is broken, and that we need to make these copies
> because of a real bug?  Or just to make the checker happy?  If the

Introducing wrong sharing is real bug :) But I know of no testcase where
it leads to ICE or produce wrong code without checker. Regrename is run
late, sharing is introduced just for complex instruction patterns and
not too many passes afterwards cares about sharing.

The copying occurs only when nontrivial RTX expressions are matched
that happens generally only in combiner patterns dealing with arithmetic
and corresponding set of flags that are not terribly common, so it is
sub 1% memory use growth on combine.c and PPC, 0% on i386.

However I am no longer sure I fully understand why the sharing is needed
at first place - regrename seems to have later mechanizm to deal with
match_dup and it seems to me that it only can result in mismatch when
there was invalid sharing before regrename introduced (so updating the
insn caused one copy of the matched RTX to be alterned but no other
copy).

I am now re-testing alternate patch that simply disables the code
introducing sharing in a hope that it will was just symptomatic fix for
sharing issue orignally and it will simply pass now.  I will know
results tonight.

Honza
> latter, have you measured the compile-time and memory usage to see what
> impact that has?  We'd like to avoid making the compiler slower just to
> make the checker happy -- but, of course, it might be worth a small hit
> to get the checking benefit.
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]