This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix PR27745 loop-linear code gen


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? :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]