Re: Fix PR37916 (unnecessary spilling)

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 21 Nov 2018, Richard Biener wrote:

> then this leads to wrong debug info showing a value for 'a' that never 
> existed.

var-tracking was specifically created so that the base-vars of SSA names 
aren't necessary for debug info anymore ...

> when you build this with -O -g -fno-var-tracking-assignments (VTA seems
> to hide the issue, probably due to not enough instructions in the end)

... which makes this an non-test.  Sure, if you cripple debug info 
generation you get ... crippled debug info.

> and the fact that var-tracking looks at REG_DECL for
> debug info location generation.  With VTA we get
> 
>   # DEBUG BEGIN_STMT
>   # DEBUG D#3 => a_1(D) + 1
>   # DEBUG a => D#3
>   # DEBUG BEGIN_STMT
>   a_11 = d_7(D) + 4;
>   # DEBUG D#2 => D#3 + b_3(D)
>   # DEBUG a => D#2
>   # DEBUG BEGIN_STMT
>   a_12 = a_11 + c_5(D);
>   # DEBUG D#1 => D#2 + c_5(D)
>   # DEBUG a => D#1
>   # DEBUG BEGIN_STMT
>   a_13 = a_12 + b_3(D);
>   # DEBUG a => D#1 + d_7(D)
>   # DEBUG BEGIN_STMT
>   a_9 = a_13 + a_1(D);
>   # DEBUG a => a_9

This seems to be exactly correct and reflecting the original code, i.e. 
VTA works as designed even with "invented" base variables.

> So your patch has to be much more careful to never change the LHS of 
> stmts that are adjusted (which I think reassoc already does).

I can't do much more in reassoc than what I implemented, it's constrained 
to cases where we have a known LHS.  If you think that's still too much 
then the problem needs to remain unfixed in reassoc, and it would need TER 
changes.  An easy way would be to disable TERin also of SSA names having 
no base var (essentially on the ground that it's the same base var then), 
but that probably disables TER too much, though I haven't tried.

In addition: I'd always happily trade less correct debug info (where the 
impact of the incorrectness is fairly trivial) with no stack accesses in 
inner loops; i.e. a tradeoff.


Ciao,
Michael.