This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [lno] some cleanups for scev
On Thu, Apr 15, 2004 at 06:43:15PM +0200, Zdenek Dvorak wrote:
> Hello,
>
> > > Perhaps you could write a more complete example, so that it can be seen
> > > what you have in mind?
> > >
> >
> > Yes, here it goes:
> >
> >
> > Example1:
> >
> > loop_1
> > a = phi (3, c)
> > d = foo ()
> > c = a + d
> > endloop_1
> >
> > I still want to have a -> {3, +, d}
>
> this makes a lot of code dependent on scev wrong. In particular
> anything that tests "no_evolution_in_loop_p" will get wrong results
> when testing such expressions. Similarly, detection of number of
> iterations will get wrong results when expressions like this are
> produced, since there is no indication that d may have different values
> in different iterations and constant folding does not count with this.
>
Yes, you're right, but the number of iterations is computed only after
full instantiation of the chrecs.
> What I would like to obtain for this expression is either
> {3, +, chrec_top}, or chrec_top directly.
>
Indeed, this is what I would like to have, but only after the
instantiation.
In fact there are two kind of chrecs: those used by the analysis
algorithm, and those that are used by the client passes. During the
analysis it is possible to keep a part of the evolution under a
symbolic form without being completely instantiated. This mechanism
allows to postpone a part of the analysis until the instantiation
step, and is used in place of the scheduling of the analysis.
(This makes me think that returning chrec_top in
instantiate_parameters when a parameter cannot be instantiated could
be the solution to this problem.)
> Or do you have any example where the usage of symbolic values would
> actually be useful?
>
Maybe the dependence analysis can deal with non fully instantiated
chrecs, but for the moment it systematically instantiate all the
chrecs.