[Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc

[Jakub Jelinek]

On Mon, Apr 20, 2015 at 10:30:32PM +0930, Alan Modra wrote:
> > and there could be other debug insns for the same variable on that path,
> > say saying that decl lives in some other register, or can be computed using
> > an expression involving other registers, or memory etc.  Say you could have
> 
> Yes, that's true in the general case.  For the shrink-wrap case, any
> bb (or tail of the entry block) that we move over has no use or def of
> the register.  So I'm left wondering how it would be possible for the
> var to live in some other register or memory?  Probably lack of
> imagination on my part, but the only scenarios I see would involve a
> failure of cse.

E.g. the variable might have different values in the source code.
You can have
  int var1 = 5;
  // some statements
  var1 = parmx + 20;
  // some statements
  var1 = 30;
  // ...
in the source and consider that the shrink wrapping insn is attempting to move
(set (regX) (plus (reg parmx) (const_int 20)))
later.  You could have different debug insns for the same var1, and trying
to move the debug_insn later would break things.  Usually, gcc only adds
further debug stmts (or insns), e.g. if in a range between earlier two debug
stmts (or insns) the var is known to contain some particular value, but
expression having that value or something used in it (SSA_NAME, pseudo REG),
is optimized away, if there is some other way to get the same value, the
range could be split into two with two different expressions etc.

> Arrgh!  In the first place the ranges are wrong since r4 dies after
> the bl, not the toc restoring nop.  Worse, both deleting and zapping
> (ie UNKNOWN_VAR_LOC) the debug insn is wrong.  My simplistic patch
> isn't correct.  In fact it makes the debug info worse.  However,

Zapping is conservatively correct, if you don't know where the var lives in
or how to compute it, you tell the debugger you don't know it.
Of course, it is a QoI issue, if there is an easy way how to reconstruct the
value otherwise, it is always better to do so.

> leaving the debug insn alone says "mode" lives in r30, but that is
> wrong since the copy to r30 insn has been moved, to 5d34.  Apparently
> the move causes the virgin location lists to say "mode" disappears at
> that point too.  What a mess!
> 
> Of course, all this moving for shrink-wrap is senseless in a block
> that contains a call.

Yeah, such blocks clearly aren't going to be shrink-wrapped, so there is no
point to move it that far, right?

	Jakub