This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [scev] Improve the instantiation pass for graphite
- From: Tobias Grosser <grosser at fim dot uni-passau dot de>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, gcc-graphite <gcc-graphite at googlegroups dot com>
- Date: Wed, 02 Sep 2009 10:49:50 +0200
- Subject: Re: [scev] Improve the instantiation pass for graphite
- References: <2374_1251846541_4A9DA98C_2374_148_1_cb9d34b20909011608g1e4c993by98274955c9d6c6a2@mail.gmail.com>
Hi Sebastian
On Tue, 2009-09-01 at 18:08 -0500, Sebastian Pop wrote:
> Hi,
>
> I will need the attached set of patches to be able to remove the limit_scop
> function in graphite. The patch set cleans up the instantiation pass, and
> allows the instantiation of variables without calling the scev analysis.
Great to see you work on this. I also gave it a try yesterday and there
are still some bugs in graphite code generation hidden by limit_scops.
> The canonical example is like this: suppose we want to instantiate everything
> below bb2 but without going to bb1:
>
> bb1:
> i = phi (0, i + 1)
>
> bb2: (this is the scop entry for example)
> j = i + 3
>
> bb3:
> use (j)
So what whould j and i be instantiated in bb_2? i seems to be a
parameter and therefore j is just (i + 3)?
An interesting case for me seems something like this:
bb_1:
i_1 = phi (0, i_0)
goto bb_2
bb_2:
i_0 = i_1 + 1
goto bb_3
bb_3:
A[i_0] = A[i_1]
if (i_1 < 100)
goto bb_1
else
return
Let's assume we start from bb_2 and want to instantiate up to and
including bb_1. As bb_3 is not included we do not get the whole loop, so
defining 'i_1' in function of the loop iteration like i_1 = {0, +, 1}_1
seems to be wrong.
However if we include bb_3 it is perfectly OK to use the definition
i_1 = {0, +, 1}_1 for 'i_1', as 'i_1' no longer is a parameter.
So for me just defining the upper bound seems to be not sufficient. We
also need to know if we have to follow the loop backwards edge or not.
> Starting the instantiation of j from bb3, we end on bb2 that is still
> in the scop,
> but we do not want to go to bb1 and instantiate i with its scalar evolution.
> I committed these patches to the graphite branch to be tested.
It seems the bootstrap failed.
Tobi