This is the mail archive of the gcc-patches@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: RFA: autoincrement patches for gcc 4 - updated patch


Bernd Schmidt wrote:

Richard Henderson wrote:

On Tue, May 17, 2005 at 12:29:04PM +0200, Bernd Schmidt wrote:

Ugh. I worked on this code back when I was at Red Hat, and as far as I recall it never worked correctly in any of its incarnations. Also, the cost estimates are pretty sh specific.



Do you have specific concerns?


First off, I can no longer reproduce the failures I saw a while ago with an earlier version of this patch, so it seems to have improved somewhat. I still have a few concerns though.

The way it re-uses existing pseudo reg numbers has proven to be extremely brittle; it's very easy to get confused about the lifetimes. I'd prefer an approach that just allocates new pseudos - we seem to have the ability now to turn off no_new_pseudos temporarily, and we might as well use it.

That's an interesting idea, but the interactions with the register allocator are so profound that this probably needs at least a few months benchmarking
and tweaking to see if it makes sense. There are certainly some cases where it is important to re-use a register to avoid unnecessary reg-reg copies.
Trying to fit this in now would probably make us miss gcc 4.1 .
The register lifetimes actually havn't been an isue recently; much more trouble was the shift of the gcc code base, first the change in the meaning
of REG_DEAD / REG_UNUSED notes, then new accessor macros, a new C dialect, changing basic block boundaries and their representation,
and finally the abort -> gcc_assert shift. This code base shift will be much easier to manage when this pass is integrated into mainline.
Allocating new pseudos is certainly something to consider when extending this optimization to work across multiple basic blocks. Now that
we have dominator / post-dominator infrastructure, and better data flow information, we could basically skip over irrelevant conditional
adjustments to other variables, and ignore out edges where all the registers in the set of registers containing related values die. Such cross-block
optimizations can be done much saner when we allocate new registers.


As far as sh-specific assumptions go, it assumes that adds are 2-address insns, and it does not take into account machines with more addressing modes - it

That's one of the reasons why it lives in regmove. regmove was originally intended only for machines that are mostly or totally two-address machines,
but Richard Kenner thought it would be beneficial to run the code on any machine that has some matching constraints.
If this optimization is not useful for a particular target, you can turn it off in OPTIMIZATION_OPTIONS.


doesn't try to generate or modify offsetted addresses as far as I can see or remember. Neither does it try to use post-modify for machines that have it.

I had some variants of this patch to handle pre/post-modify, and even some concepts how to integrate a partial ability to use reg+offset addressing,
but I couldn't justify polishing up these while working on sh4 / sh5 optimizations, since pre-post_modify applies only to sh-dsp within the SH family,
and there only for insns that gcc can't handle in the first place. There would be a few applications where floating point values and integer values
are in the same struct and could be handled more efficiently with support for reg+offset addressing, but other things like unrolling improvements
and giv widening were much more effective at improving code quality. These also increase the opportunities for optimize_related_values.



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