On Fri, May 20, 2011 at 08:27, Basile Starynkevitch
<bas...@starynkevitch.net> wrote:
>> What is your definition of induction variable?
>
> The one which is used by graphite.
Ok, then you can match against the scalar evolution of a variable:
the evolution of your variable should be of the form "{a, +, 1}_x"
with "x" the number of the loop you are looking at, and "a"
a constant with respect to loop number "x".
Look at tree-scalar-evolution.[ch] where there are functions that
you can call for this kind of pattern matching.
> I believe that the cleanest way to avoid that would be to have graphite
> invoke a plugin hook to signal the creation of that induction variable.
> For instance, we could add, in the function graphite_create_new_loop
> file gcc/graphite-clast-to-gimple.c (rev 172785 of the trunk), just
> after the call (near line 783) add_referenced_var (ivvar); a
> invoke_plugin_callbacks (PLUGIN_GRAPHITE_NEW_INDUCTION_VARIABLE, ivvar);
> I really think that several plugins could profit of such a hook.
I don't think that marking a specific variable as "the main induction
variable of a loop" is the right thing to do: other passes may just decide
to remove it and then you should also update your information.
> What do you think of such an idea? More generally, I believe that
> graphite is lacking of several plugin hooks (and by discussing with
> some INRIA people, I understood -perhaps wrongly- that they would also
> want them).
>
> Do graphite folks want to add plugin hooks inside graphite before 4.7?
We already have a way to export the polyhedral representation and
to read it back: that should be enough to write some kind of "plugins".
Sebastian
