Re: [RFC] IPA constant propagation - very preliminary code

[Jan Hubicka <jh at suse dot cz>]

> On Tuesday 08 June 2004 16:53, Razya Ladelsky wrote:
> > Hello,
> >
> > Following our message ( http://gcc.gnu.org/ml/gcc/2004-05/msg00710.html)
> > I enclose a very preliminary version of the code implementing IPA constant
> > propagation.
> > The code is of course not fully functional, but it does demonstrate the
> > constants that it
> > identifies in simple examples (by printing these values).
> > Comments are welcome!
> 
> First of all, very cool to see how quickly this is progressing.

Yep,  I can`t review the patch right now, but will definitly do after
returning from the vacation at 14th unless someone beats me.
Thanks for the work!
> 
> One comment on where you put stuff:
> 
> > ===================================================================
> > RCS file: /cvsroot/gcc/gcc/gcc/cgraph.h,v
> > retrieving revision 1.32
> > diff -c -3 -p -r1.32 cgraph.h
> > *** cgraph.h	22 May 2004 18:16:38 -0000	1.32
> > --- cgraph.h	8 Jun 2004 11:45:39 -0000
> > *************** struct cgraph_rtl_info GTY(())
> > *** 70,75 ****
> > --- 70,105 ----
> >      bool pure_function;
> >   };
> > 
> > + /* The following definitions are used by
> > +    IPA Constant Propagation algorithm.  */
> > + enum Jfunc_type {
> > +             UNKNOWN_IPATYPE,
> > +             CONST_IPATYPE,
> > +             FORMAL_IPATYPE
> > + };
> > + enum Cvalue_type {
> > +             BOTTOM,
> > +             CONST_VALUE,
> > +             TOP
> (...)
> 
> Can you not put this in a a separate header?  It has nothing to
> do with the call graph as such, so...
> 
> Also, Honza/me have plans to split up the call graph code more
> properly.  I have a cgraphanal.c in my local tree (doing the top
> sort and finding SCCs in the call graph), it's nice if you could
> put your jump functions in a separate header too (ipa-prop.h?

My plan is to keep cgraph.c to contain only the datastructure bits
perhaps breaking up the variable pool into varpool.c and dropping the
missleading cgraph_ prefix in naming scheme.

Then break out the inliner heuristics into inline-heuristics.c and rest
of the very trivial optimizations into the cgraphopt.c so I hope that
cgraphunit.c will become less than 300 lines of magic related to driving
the compilation process (particularly all the bits related to various
types of functions we have - extern, static, inline, comdat, extern
inline).  Having cgraphanal.c sounds like good idea too and I would like
to break up the header too

Honza
> 
> Gr.
> Steven
>