This is the mail archive of the gcc@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: Dropping of old loop optimizer


Hello,

> > > The "old" loop optimizer does BIV-to-GIV flattening which is important on
> > > processors without double-register addressing modes such as the SH,
> > > MIPS16, Thumb, and a few others.
> > > 
> > > Does the new loop optimizer support this feature?
> > 
> > no; as I said, anything related to iv's is problem.
> > 
> 
> Right now I'm working on a pass that enrich the SSA representation 
> by the IV functions information.  IVs are represented by chains of
> recurences as described in:
> 
> http://citeseer.nj.nec.com/485503.html
> http://citeseer.nj.nec.com/vanengelen00symbolic.html
> 
> In contrast to these papers I'll not transform the underlying 
> representation, but enrich SSA with symbolic information that 
> analyzers, as the dependence tester, or optimizers will use.
> 
> As long as you have an SSA representation over RTL it should be 
> straight to implement it from the tree-SSA.  

The problem I see is that rtl ssa is broken (or never worked?); but
perhaps we could do this kind of optimizations just on trees (that
unfortunately also aren't ready for serious usage yet, right?)?

> Right now I have a working multivariate and periodic CR system.  
> I have extended the CR system to flip-flop operations that introduce 
> periodicity effects.
> 
> I still work on extending the CR system to undefined operations 
> that nor Zima, nor Engelen defined (for example the multiplication 
> of exponential CRs by polynomial CRs, or the addition of exponential CRs).
> I will perform these operations symbolically without expecting to 
> have a code generator at the end as it is the case in the previous papers.  
> I think that analyzers and optimizers should be implemented without mixes.
> 
> Interfacing with the existing tree-SSA is the next step in my todo list.
> Then I'll look at how it could be adapted to RTL.

How long do you think it will take you before the result is usable (I
wonder whether it makes sense to work on some temporary, not so clean
but faster solution)?

Zdenek


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