This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR27745 loop-linear code gen
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 29 May 2006 11:12:47 -0400
- Subject: Re: [patch] Fix PR27745 loop-linear code gen
- References: <20060529233132.GB5346@napoca.cri.ensmp.fr>
Sebastian Pop wrote:
> Hi,
>
> the problem in pr27745 is that perfect nestify is duplicating too much
> code, and is infinitely looping over a same statement that is copied
> again and again:
>
> pretmp.24_42 = pretmp.24_9 + -101;
> [...]
> D.1266_29 = pretmp.24_42;
> D.1267_30 = D.1265_28 + pretmp.24_42;
>
> is transformed to the following code:
>
> pretmp.24_50 = pretmp.24_9 + -101;
> pretmp.24_49 = pretmp.24_9 + -101;
> D.1266_29 = pretmp.24_50;
> D.1267_30 = D.1265_28 + pretmp.24_49;
>
> The same statement is duplicated with different names the number of
> imm_uses times!
This wasn't true in the past, so something broke it :)
By the way, why are the uses of a SSA_NAME called
> immediate uses? Is that they are the uses of the same declaration,
> i.e. scalar dependences with a distance 1, in contrast to transitive
> scalar dependences?
They are just the end of the def-use chain, but as you say, are not
transitive, and only distance 1. It used to be the case that the
immediate uses gave you only statements. These statements were the
"immediate" users of the operand in question. Now that it gives
pointers to opreands, etc, it's a bit wonkier to call them "immediate" uses.
>
> The solution is to not copy the statements but instead move them to
> the inner loop.
We used to do this, however ....
This transformation is safe because if there are
> other statements in the outer loop that use the variables defined by
> the moved statements, they are either also moved in the inner loop, or
> moved to the next loop. If the other uses cannot be moved from the
> outer loop, can_convert_to_perfect_nest should return false.
There were cases where we wanted to be able to copy statements that were
used both inside the inner loop, *and* after the entire inner loop was
finished, and it was safe to copy them to both places (we verified this).
In particular, we had some cast instructions that ended up like this.
For the moment, we should probably just do the moving thing again, since
that matches can_convert_to_perfect_nest again, so this patch is fine.
Have i ever mentioned how happy i'll be when all this code goes the way
of the dodo? :)