This is the mail archive of the
mailing list for the GCC project.
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
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
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
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
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
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
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
are in the same struct and could be handled more efficiently with
support for reg+offset addressing, but other things like unrolling
and giv widening were much more effective at improving code quality.
These also increase the opportunities for optimize_related_values.