Re: debug_hooks->end_prologue problem

[Eric Botcazou]

> If you compile without optimization, then this is the same as the
> prologue end.  If you compile with optimization, then the function body
> and the prologue overlap.  Now the question is, do you really want to
> mark the beginning of the function body (which may be before the
> prologue end), or the end of the prologue (which may be after the
> function body beginning).  Either way, it is likely that someone may not
> be happy.  However, in general, the former (function body beginning) is
> more useful to end users, as otherwise they won't be able to debug all
> of the code in the function body.  So the current code in final.c looks
> correct.

Yes, the code in final.c is OK.  However, there is a bug pertaining to the 
placement of the NOTE_INSN_FUNCTION_BEG note for parameterless functions.

void foo(void)
{
  int i = 0;
}

In .flow2 at -O0:

(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)

;; Start of basic block 3, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame]
(note 6 3 19 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn/f 19 6 20 3 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
        (reg/f:DI 6 bp)) -1 (nil)
    (nil))

(insn/f 20 19 21 3 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) -1 (nil)
    (nil))

(note 21 20 8 3 NOTE_INSN_PROLOGUE_END)


void bar(int par)
{
 int i = 0;
}

(insn/f 20 6 21 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
        (reg/f:DI 6 bp)) -1 (nil)
    (nil))

(insn/f 21 20 22 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) -1 (nil)
    (nil))

(note 22 21 3 2 NOTE_INSN_PROLOGUE_END)

(insn 3 22 4 2 (set (mem/c/i:SI (plus:DI (reg/f:DI 6 bp)
                (const_int -20 [0xffffffffffffffec])) [0 par+0 S4 A32])
        (reg:SI 5 di [ par ])) 40 {*movsi_1} (nil)
    (nil))

(note 4 3 9 2 NOTE_INSN_FUNCTION_BEG)


function.c:thread_prologue_and_epilogue_insns has code to fix up the order of 
NOTE_INSN_FUNCTION_BEG and NOTE_INSN_FUNCTION_END notes for the epilogue, but 
not for the prologue.  We've found out in the meantime that it was the root 
cause of Doug's problem and fixed it locally.

> Othogonal to this, there is the problem of what to do with these notes
> when instruction scheduling is enabled.
> [...]
> It isn't clear if this extra work is worthwhile.

Yes, the interaction with scheduling is another, more difficult problem.  And 
I don't think we really care about it for Doug's work.

Thanks for your feedback.

-- 
Eric Botcazou