Re: [PATCH] Fix debug info for expr and jump stmt

[Dehao Chen <dehao at google dot com>]

On Mon, Oct 29, 2012 at 7:17 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 29 Oct 2012, Richard Biener wrote:
>
>> > Well, you merely moved the bogus code to gimple-low.c.  It is bogus
>> > because you unconditionally overwrite TREE_BLOCK of all operands (and all

Emm, then in gimple-low.c, we should probably not unconditionally
overwrite gimple_block for stmts too?

>> > operands operands) with the statements block.  I assume the unit-test you
>> > added shows the problem you were trying to fix?
>> >
>> > From the scan-assembler-no directive I'm not really sure what exactly the
>> > problem is you're seeing.  Can you try to describe it with words for the
>> > example code?  Which operands has no tree-block where it should have one,
>> > or which one has the wrong tree-block?
>>
>> trees without block could be an issue when we extract them to some other
>> statement (then without block), and move that to some random place.
>
> Even then it would be either the frontends job to set the block, or the
> the job of the pass that introduced the new expression, when there is a
> clearly sane candidate for the block.

Please correct me if I'm wrong: front-end does not set blocks for
either stmt/expr. lower_stmt is the first place that block is set for
stmt, thus I think it should also be the first place to set block for
expr.

>
>> But the only issue should be that the stmt/expressions effective block
>> becomes a different one (the currently "active" one during expansion).

I agree. Initially, both stmt and expressions is set to NULL block.
Whenever we update the stmt's block, we should also update the
expression's block, otherwise they will be inconsistent.

>
> Yep.
>
>> I don't see how we could end up generating too many block location
>> DIEs because of this.

For the unittest I added, all the assembly code guarded by "if" are
should be within one lexical block, which is lock:

  LBB1
  {
    asm1
    asm2
    asm3
    asm4
    ....
  }

However, because some expression are with NULL lexical block, these
assembly codes are separated by several discontinual lexical block
which is like:

   LBB1
    {
       asm1
    }
  asm2
  LBB2
    {
       asm3
    }
  asm4
  ....

>
> And even if, I don't see what's the _problem_ with too many block
> locations, except bloat.

Yes, bloat is the major problem.

Thanks,
Dehao

>
>
> Ciao,
> Michael.