This is the mail archive of the gcc-bugs@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]

[Bug rtl-optimization/54133] regrename introduces additional dependencies


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133

--- Comment #7 from amker.cheng <amker.cheng at gmail dot com> 2012-08-02 10:18:41 UTC ---
(In reply to comment #6)
> > In experiment, if I disable r0/r1 from renaming, most regressions observed in
> > CSiBE are gone.
> > 
> > So how should this be fixed? Thanks.
> 
> The choice of the renaming register can be parameterized at the class level,
> but I'm not sure this would work here.  You could also try to add some
> additional heuristics for this choice, as it seems to be clearly
> counter-productive here.

My bad that I did not mention details of the method by disabling r0/r1 from
renaming.
When comparing to trunk(where regrename is disabled for Os), the method fixes
most of regrenaming regressions, which is good.
But it is too conservertive that some renaming opportunities are missed. From
the view of code size: data show that this method has 700/440 bytes
benefit/regression against the current implemention of regrename. This means
only 250 bytes benefit overall.
The data is collected from CSiBE on arm cortex-m0.

Giving that the regressions may cross basic_block, it's hard to fix them in
regrenaming without missing renaming opportunities.

Is it possible to run regcprop pass both before and after regrenaming?


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