Line number notes revamp?

Line number notes revamp?

[Jan Hubicka]

Hi,
while I am at the grand cleanups, I got idea to reorganize way line number
notes are handled.  To my opinion, the current way of emitting line number
notes to the insn stream is goot for RTL construction pass, but nightmare
to keep up to date when performing code motion.

Exception handling gets around quite easilly by using note in the generation
and then convert it to the REG notes.  I think for line numbers we should use
same - have REG_LINENUM note that has value pointing to the linenum record -
eighter represented in RTL as (linenum line column string) or separately.  (we
may want to attach multiple lines to single insn in combining).

I believe that this is more robust for optimizers - newly generated code will
miss lines, but for a lot of code this is OK (such as register spilling),
later we may add linenum_emit_insn instruction familly to handle this in cases
we want to emit new instruction with line number information atached.

I promise from the solution following
  - more exact debug information  (even with optimizing)
  - no more problems with different code generated at -g
  - easier code in scheduler
  - one purpose fewer to have something in between basic blocks

If this sounds sane, I would probably try to do that next week on the CFG
branch.

What do you think?

Honza

Re: Line number notes revamp?

[Richard Henderson]

On Wed, Sep 12, 2001 at 04:46:43PM +0200, Jan Hubicka wrote:
> I think for line numbers we should use same - have REG_LINENUM note
> that has value pointing to the linenum record - eighter represented
> in RTL as (linenum line column string) or separately.

I think having a dedicated field in the INSN rtx will use less space.

We could have a magic value (0?) that means "no assigned line number",
which means that no line number entry is emitted for this insn, which
means it appears at whatever line number is assigned to some preceeding
insn.

> (we may want to attach multiple lines to single insn in combining).

Why?  How would you represent this in the debug format?

> later we may add linenum_emit_insn instruction familly to handle this in cases
> we want to emit new instruction with line number information atached.

Possibly.  But there are lots of insns that we emit (particularly spill
code) for which no line number is necessarily appropriate.


r~

Re: Line number notes revamp?

[Daniel Berlin]

Richard Henderson <rth@redhat.com> writes:

> On Wed, Sep 12, 2001 at 04:46:43PM +0200, Jan Hubicka wrote:
> > I think for line numbers we should use same - have REG_LINENUM note
>> that has value pointing to the linenum record - eighter represented
>> in RTL as (linenum line column string) or separately.
>
> I think having a dedicated field in the INSN rtx will use less space.
>
I did this, and it puts the RTX's into the next bucket.
You need column number as well.

> We could have a magic value (0?) that means "no assigned line number",
> which means that no line number entry is emitted for this insn, which
> means it appears at whatever line number is assigned to some preceeding
> insn.
>
>> (we may want to attach multiple lines to single insn in combining).
>
> Why?  How would you represent this in the debug format?
>
>> later we may add linenum_emit_insn instruction familly to handle this in cases
>> we want to emit new instruction with line number information atached.
>
> Possibly.  But there are lots of insns that we emit (particularly spill
> code) for which no line number is necessarily appropriate.
>
>
> r~

-- 
"I bought some powdered water, but I don't know what to add to it.
"-Steven Wright

Re: Line number notes revamp?

[Richard Henderson]

On Wed, Sep 12, 2001 at 04:48:53PM -0400, Daniel Berlin wrote:
> I did this, and it puts the RTX's into the next bucket.

As opposed to allocating 

	(EXPR_LIST:REG_LINENO (const_int 10101))

for every instruction?  Further, we can add any random bucket size
we like.

> You need column number as well.

No I don't.  We don't have one now.  Further, I thought Niel was
talking about hashing file+line+column together into a single number.


r~

Re: Line number notes revamp?

[Daniel Berlin]

Richard Henderson <rth@redhat.com> writes:

> On Wed, Sep 12, 2001 at 04:48:53PM -0400, Daniel Berlin wrote:
> > I did this, and it puts the RTX's into the next bucket.
>
> As opposed to allocating 
>
> 	(EXPR_LIST:REG_LINENO (const_int 10101))
>
> for every instruction?
I didn't say we *shouldn't*, just that it pushed them into the next
bucket.
But on the other side, we only need notes we want to have line numbers on.
This isn't necessarily every instruction.
You could also probably find a way to share the notes, so for a given
line number, they are only allocated once.
However, i don't think the advantage is large enough to warrant doing
it, as opposed to the simplicity just putting them in the INSN's gives
you.

>  Further, we can add any random bucket size
> we like.
Given.
>
>> You need column number as well.
>
> No I don't.  We don't have one now.  Further, I thought Niel was
> talking about hashing file+line+column together into a single
> number.
But having a single number is not done now, nor is it near the top of
Neil's priority list, 
I would imagine.
Changing the line numbers to be embedded in RTL is actually pretty trivial.
I have a patch to do it already, from the last time i suggested we
move them into the RTL.
However, it added a column number and file number to the RTL as well,
since this one magic number does not exist right now.
>
>
> r~

-- 
"Ever notice how irons have a setting for *permanent* press?  I
don't get it...
"-Steven Wright

Re: Line number notes revamp?

[Neil Booth]

Richard Henderson wrote:-

> > You need column number as well.
> 
> No I don't.  We don't have one now.  Further, I thought Niel was
> talking about hashing file+line+column together into a single number.

No, I've put file + line into a single number, but since we wanted to
be able to support really large files, column numbers will be a
separate 16-bit quantity to line numbers.  I have no intention of
doing much else in this area; I don't think much can be done.

Neil.

Re: Line number notes revamp?

[Zack Weinberg]

On Thu, Sep 13, 2001 at 07:00:29AM +0100, Neil Booth wrote:
> Richard Henderson wrote:-
> 
> > > You need column number as well.
> > 
> > No I don't.  We don't have one now.  Further, I thought Niel was
> > talking about hashing file+line+column together into a single number.
> 
> No, I've put file + line into a single number, but since we wanted to
> be able to support really large files, column numbers will be a
> separate 16-bit quantity to line numbers.  I have no intention of
> doing much else in this area; I don't think much can be done.

On the other hand, how useful are column numbers at the RTL level?  In
trees, particularly in VAR_DECLs and the like, I can see it, but not
when we're talking about whole statements at a time.

It *would* be useful to be able to distinguish multiple statements on
a line, but (a) I don't think we need the whole column number for
that, and (b) I've never seen a debugger that could handle it.
What's DWARF capable of?

zw

Re: Line number notes revamp?

[Neil Booth]

Zack Weinberg wrote:-

> On the other hand, how useful are column numbers at the RTL level?  In
> trees, particularly in VAR_DECLs and the like, I can see it, but not
> when we're talking about whole statements at a time.
> 
> It *would* be useful to be able to distinguish multiple statements on
> a line, but (a) I don't think we need the whole column number for
> that, and (b) I've never seen a debugger that could handle it.
> What's DWARF capable of?

True; I've only ever intended their use for diagnostics.  So probably
only the front end needs them.

Neil.

Re: Line number notes revamp?

[Richard Henderson]

On Wed, Sep 12, 2001 at 11:58:00PM -0700, Zack Weinberg wrote:
> What's DWARF capable of?

Both column and line number, statement and statement fragment.


r~

Re: Line number notes revamp?

[Jan Hubicka]

> Richard Henderson wrote:-
> 
> > > You need column number as well.
> > 
> > No I don't.  We don't have one now.  Further, I thought Niel was
> > talking about hashing file+line+column together into a single number.
> 
> No, I've put file + line into a single number, but since we wanted to
> be able to support really large files, column numbers will be a
> separate 16-bit quantity to line numbers.  I have no intention of
> doing much else in this area; I don't think much can be done.

I was thinking about reserving separate field in instruction overnight too.
I believe it should be done in a way that the field points to LINFO RTX,
that has needed information - that way we can add column or whatever
we want later w/o renumbering fields in the INSN rtx itself.

Also I see one problem with GCOV.  For that pass our current behaviour
is far supperrior to the notes on instructions.  Be I see that:
1) in longer term, profiling should be very first optimization pass, so we can
   kill line notes afterwards
2) it may make sense to give up gcov on the optimized code in short term, as it
   don't work currently perfectly anyway.

Otherwise if the plan sounds resonable, I will probably invest my time into
it, once I am finished with the CFG cleanups I am working on currently.

Concerning the new inssn - I agree that for spilling code we don't want
to attach line number.  Case where we want to is instruction splitting and
combinning, so we definitly need to be able do both.

Concerning multiple statements per single instruction - I am also not quite
sure it makes sense. Is there some debug format able to do that?

Honza
> Neil.

Re: Line number notes revamp?

[Daniel Berlin]

Zack Weinberg <zack@codesourcery.com> writes:

> On Thu, Sep 13, 2001 at 07:00:29AM +0100, Neil Booth wrote:
> > Richard Henderson wrote:-
>> 
>> > > You need column number as well.
>> > 
>> > No I don't.  We don't have one now.  Further, I thought Niel was
>> > talking about hashing file+line+column together into a single number.
>> 
>> No, I've put file + line into a single number, but since we wanted to
>> be able to support really large files, column numbers will be a
>> separate 16-bit quantity to line numbers.  I have no intention of
>> doing much else in this area; I don't think much can be done.
>
> On the other hand, how useful are column numbers at the RTL level?  In
> trees, particularly in VAR_DECLs and the like, I can see it, but not
> when we're talking about whole statements at a time.
>
> It *would* be useful to be able to distinguish multiple statements on
> a line, but (a) I don't think we need the whole column number for
> that, and (b) I've never seen a debugger that could handle it.
> What's DWARF capable of?
It can do it, AFAIK.
We just don't use the info.

>
> zw

-- 
"Ever notice how irons have a setting for *permanent* press?  I
don't get it...
"-Steven Wright

Re: Line number notes revamp?

[Daniel Berlin]

Jan Hubicka <jh@suse.cz> writes:

>> Richard Henderson wrote:-
>> 
>> > > You need column number as well.
>> > 
>> > No I don't.  We don't have one now.  Further, I thought Niel was
>> > talking about hashing file+line+column together into a single number.
>> 
>> No, I've put file + line into a single number, but since we wanted to
>> be able to support really large files, column numbers will be a
>> separate 16-bit quantity to line numbers.  I have no intention of
>> doing much else in this area; I don't think much can be done.
>
> I was thinking about reserving separate field in instruction overnight too.
> I believe it should be done in a way that the field points to LINFO RTX,
> that has needed information - that way we can add column or whatever
> we want later w/o renumbering fields in the INSN rtx itself.

Then you run into the problem Richard pointed out, that we end up
allocating an extra 4 bytes (minimum) for each RTX with a line number.
It's cheaper to just put them directly in the RTX.

You only need to add one or two fields to the end of INSN, CALL_INSN,
and JUMP_INSN.

>
> Also I see one problem with GCOV.  For that pass our current behaviour
> is far supperrior to the notes on instructions.  Be I see that:
> 1) in longer term, profiling should be very first optimization pass, so we can
>    kill line notes afterwards
> 2) it may make sense to give up gcov on the optimized code in short term, as it
>    don't work currently perfectly anyway.
>
> Otherwise if the plan sounds resonable, I will probably invest my time into
> it, once I am finished with the CFG cleanups I am working on
> currently.
Would you like the patch I have which modifies rtl.h and everywhere
else to use a line number in RTX (The tricky parts are in final.c)?

It definitely improves our line numbers for optimization.

Currently, we jump around and such, so that "next" on a line that
inits a variable, really doesn't init the variable until the second
time you hit that line (IE GDB jumps back to it again). With the
patch, we don't have this problem.

>
> Concerning the new inssn - I agree that for spilling code we don't want
> to attach line number.  Case where we want to is instruction splitting and
> combinning, so we definitly need to be able do both.
>
> Concerning multiple statements per single instruction - I am also not quite
> sure it makes sense. Is there some debug format able to do that?
Yes.
DWARF2 can do it, since it supports statement fragments and whatnot.

>
> Honza
> > Neil.

-- 
"If you were going to shoot a mime, would you use a silencer?
"-Steven Wright