Re: Line Number Table Issue

[brender at gemgrp dot zko dot dec dot com (Ron 603-884-2088)]

Brian,

Concerning the proposal in your mail of 17 May specifically:

>Proposal for DWARF 2.1 change:
>------------------------------
>
>This change modifies the is_stmt register of the state machine to have an
>initialized value of "true", and clarifies the responsibility of a pipeline
>scheduling code generator to identify some instruction as the "beginning" of
>a source line.
>
>Textual changes to the specification:


>6.2 Line Number Information
>...
>Such a matrix, however, would be impractically large.  We shrink it with two
>techniques.  First, we delete from the matrix each row whose file, line and
>source column information is identical with that of its predecessors.  [new
>text] Any deleted rows would never be the beginning of a source statement.
>[end new text]
>...

>6.2.2 State Machine Registers
>...
>is_stmt   A boolean indicating that the current
>          instruction is the beginning of a
>          statement.
>
>          [new text] Every distinct line number
>          within should always have one and
>          only one instruction for which this
>          boolean is true.  Except in the case
>          of inlining or template expansion
>          where a line number is semantically
>          repeated in a source file, then each
>          expansion of a line number should
>          always have one and only one
>          instruction for which this boolean
>          is true.
>
>          A simple code generator that emits
>          machine instructions in the order
>          implied by the source program would
>          never modify this register and every
>          entry in the matrix would represent
>          a statement boundary.  A pipeline
>          scheduling code generator might mark
>          some instructions as false when
>          instructions from several source
>          statements are intermixed.[end new text]
>...
>At the beginning of each sequence within a statement program, the state of
>the registers is:
>...
>is_stmt   [modified text] "true" [end modified text]
>basic_block ...

>6.2.4 The Statement Program Prologue
>...
>5. [modified text] unused (ubyte)
>   This byte is currently unused. [end modified text]
>
>6. line_base (sbyte)
>...

In addition to "inlining or template expansion", there are a variety of
other optimizations that can complicate the goal expressed. Ones that
come to mind include:

  - loop unrolling, which replicates the body of a loop some number of times
  - node splitting, such as performed to make a non-reducible flow graph
	in a reducible one
  - code scheduling that moves an instruction earlier past a join (which
	means duplicating the instruction on multiple paths)
  - trace scheduling which picks a key path through the code to optimize,
	and inserts compensating extra (duplicate instructions) on other
	paths that join or split off,
  - and on and on

The converse problem also exists

  - dead store elimination, which eliminates lines that should be present
  - CSEs, which also can eliminate lines

When it comes to optimized code, there is probably little that the DWARF2
document can say beyond something like "do something sensible consistent
with the kind of optimization being performed" and leave "sensible" up
to the good judgement of the compiler implementor.