* Line number notes revamp? @ 2001-09-12 7:46 Jan Hubicka 2001-09-12 13:05 ` Richard Henderson 0 siblings, 1 reply; 12+ messages in thread From: Jan Hubicka @ 2001-09-12 7:46 UTC (permalink / raw) To: gcc, rth 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 7:46 Line number notes revamp? Jan Hubicka @ 2001-09-12 13:05 ` Richard Henderson 2001-09-12 13:48 ` Daniel Berlin 0 siblings, 1 reply; 12+ messages in thread From: Richard Henderson @ 2001-09-12 13:05 UTC (permalink / raw) To: Jan Hubicka; +Cc: gcc 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~ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 13:05 ` Richard Henderson @ 2001-09-12 13:48 ` Daniel Berlin 2001-09-12 13:56 ` Richard Henderson 0 siblings, 1 reply; 12+ messages in thread From: Daniel Berlin @ 2001-09-12 13:48 UTC (permalink / raw) To: Richard Henderson; +Cc: Jan Hubicka, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 13:48 ` Daniel Berlin @ 2001-09-12 13:56 ` Richard Henderson 2001-09-12 16:11 ` Daniel Berlin 2001-09-12 23:00 ` Neil Booth 0 siblings, 2 replies; 12+ messages in thread From: Richard Henderson @ 2001-09-12 13:56 UTC (permalink / raw) To: Daniel Berlin; +Cc: Jan Hubicka, gcc 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~ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 13:56 ` Richard Henderson @ 2001-09-12 16:11 ` Daniel Berlin 2001-09-12 23:00 ` Neil Booth 1 sibling, 0 replies; 12+ messages in thread From: Daniel Berlin @ 2001-09-12 16:11 UTC (permalink / raw) To: Richard Henderson; +Cc: Daniel Berlin, Jan Hubicka, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 13:56 ` Richard Henderson 2001-09-12 16:11 ` Daniel Berlin @ 2001-09-12 23:00 ` Neil Booth 2001-09-12 23:58 ` Zack Weinberg 2001-09-13 2:56 ` Jan Hubicka 1 sibling, 2 replies; 12+ messages in thread From: Neil Booth @ 2001-09-12 23:00 UTC (permalink / raw) To: Richard Henderson, Daniel Berlin, Jan Hubicka, gcc 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 23:00 ` Neil Booth @ 2001-09-12 23:58 ` Zack Weinberg 2001-09-13 0:00 ` Neil Booth ` (2 more replies) 2001-09-13 2:56 ` Jan Hubicka 1 sibling, 3 replies; 12+ messages in thread From: Zack Weinberg @ 2001-09-12 23:58 UTC (permalink / raw) To: Neil Booth; +Cc: Richard Henderson, Daniel Berlin, Jan Hubicka, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 23:58 ` Zack Weinberg @ 2001-09-13 0:00 ` Neil Booth 2001-09-13 1:24 ` Richard Henderson 2001-09-13 5:59 ` Daniel Berlin 2 siblings, 0 replies; 12+ messages in thread From: Neil Booth @ 2001-09-13 0:00 UTC (permalink / raw) To: Zack Weinberg; +Cc: Richard Henderson, Daniel Berlin, Jan Hubicka, gcc 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 23:58 ` Zack Weinberg 2001-09-13 0:00 ` Neil Booth @ 2001-09-13 1:24 ` Richard Henderson 2001-09-13 5:59 ` Daniel Berlin 2 siblings, 0 replies; 12+ messages in thread From: Richard Henderson @ 2001-09-13 1:24 UTC (permalink / raw) To: Zack Weinberg; +Cc: Neil Booth, Daniel Berlin, Jan Hubicka, gcc 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~ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 23:58 ` Zack Weinberg 2001-09-13 0:00 ` Neil Booth 2001-09-13 1:24 ` Richard Henderson @ 2001-09-13 5:59 ` Daniel Berlin 2 siblings, 0 replies; 12+ messages in thread From: Daniel Berlin @ 2001-09-13 5:59 UTC (permalink / raw) To: Zack Weinberg Cc: Neil Booth, Richard Henderson, Daniel Berlin, Jan Hubicka, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-12 23:00 ` Neil Booth 2001-09-12 23:58 ` Zack Weinberg @ 2001-09-13 2:56 ` Jan Hubicka 2001-09-13 6:02 ` Daniel Berlin 1 sibling, 1 reply; 12+ messages in thread From: Jan Hubicka @ 2001-09-13 2:56 UTC (permalink / raw) To: Neil Booth; +Cc: Richard Henderson, Daniel Berlin, Jan Hubicka, gcc > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Line number notes revamp? 2001-09-13 2:56 ` Jan Hubicka @ 2001-09-13 6:02 ` Daniel Berlin 0 siblings, 0 replies; 12+ messages in thread From: Daniel Berlin @ 2001-09-13 6:02 UTC (permalink / raw) To: Jan Hubicka; +Cc: Neil Booth, Richard Henderson, Daniel Berlin, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2001-09-13 6:02 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-12 7:46 Line number notes revamp? Jan Hubicka 2001-09-12 13:05 ` Richard Henderson 2001-09-12 13:48 ` Daniel Berlin 2001-09-12 13:56 ` Richard Henderson 2001-09-12 16:11 ` Daniel Berlin 2001-09-12 23:00 ` Neil Booth 2001-09-12 23:58 ` Zack Weinberg 2001-09-13 0:00 ` Neil Booth 2001-09-13 1:24 ` Richard Henderson 2001-09-13 5:59 ` Daniel Berlin 2001-09-13 2:56 ` Jan Hubicka 2001-09-13 6:02 ` Daniel Berlin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).