Am Sonntag, 17. April 2005 16:26 schrieb Daniel Jacobowitz:
> On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
> > Hi,
> >
> > while lacking the deep insight into GCC internals most of you have, I'd
> > never the less like to ask you to be very prudent concerning the issue of
> > removal of seemingly unnecessary RTL optimizations.
> > In contrast to 32 bit targets, for 8 and 16 bit targets the RTL
> > representation possibly might look completely different than the
> > corresponding tree representation of the code:
> > In my opinion, now that the new tree optimizations exist, it might
> > finally be a good approach to let all the optimizations that could be
> > done on original DI/SI/HI mode expressions be done on the tree level
> > already. Then one could expand the DI/SI/HI mode expressions at RTL
> > generation to only refer to the processor's native word length modes.
> > What one would get then is a RTL which has about nothing to do with the
> > corresponding tree representation.
>
> This does not conflict with removing RTL optimizers. Right now, the
> most natural time to do this sort of lowering is at expand; but there's
> no fundamental reason why it could not be done on trees, just before
> expand, and rerun relevant tree optimizers after doing so. Same as the
> issues for "long long" splitting that Roger mentioned.
I agree that this would be also a solution and one would probably do it this
way if one rewrote gcc from scratch. Only drawback that I see is, that this
way someone who wishes to write a new back-end would then be required to
learn *two* intermediate representations simultaneously. (As a bloody
beginner, I'd like to say that even understanding how to work with RTL
sometimes is not *really* intuitive :-) ...)
\begin{offtopic}
BTW. You have mentioned the possibility to re-run a couple of optimization
passes later on.
I am presently facing a situation (AVR) where condition code issues force us
to continuing to split a couple of patterns only after reload and I think
that it would be helpful to re-run some passes after having done the
splitting. E.g. I am having sequences like
(set (subreg:QI (reg:HI 12) 0) (__some_memory_reference__))
(set (subreg:QI (reg:HI 12) 1) (const_int 0))
(set (subreg:QI (reg:HI 20) 0) (ior:QI (subreg:QI (reg:HI 20) 0) (subreg:QI
(reg:HI 12) 0)))
(set (subreg:QI (reg:HI 20) 1) (ior:QI (subreg:QI (reg:HI 20) 1) (subreg:QI
(reg:HI 12) 1)))
steming, e.g., from an ior of a zero-extended QI value in r12:r13 with a HI
value in r20:r21. While I see that it is hopless to tell GCC after reload
that it could have avoided allocating r13, I at least have the hope that the
second or-operation (on r13 and r21) and the storing of 0 into r13 could be
optimized away if a pass is re-run that is usually executed *before* reload
only.
I'd appreciate any hint on which place in the mid-end (i.e. which source file)
I might want to look at ...
\end{offtopic}
Yours,
Björn
