Re: My opinions on tree-level and RTL-level optimization

[Björn Haase <bjoern dot m dot haase at web dot de>]

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