What is the precise definition of NOTE_INSN_FUNCTION_BEG?

What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

Hi there,

I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and 
hoping someone here knows.

The gcc internal documentation says it "Appears at the start of the 
function body, after the function prologue." but this isn't very 
precise, and it seems to not distinguish between the undocumented 
NOTE_INSN_PROLOGUE_END and the NOTE_INSN_FUNCTION_BEG.

A comment in dwarf2out.c shows it's used as a marker between boilerplate 
and code corresponding to things "the user wrote".
This assumption is broken by things like -fstack-protector-strong (as 
bugzilla 88432 shows).

alias.c seems to use it to assume that argument registers have their 
original values before it (see the use of the "copying_arguments" 
variable and find_base_value function).
I'm not yet certain of this, but if that is the assumption I think this 
is also not observed.

The test file below compiles to something breaking that assumption when 
compiled with `gcc -fsanitize=address -S test.c -o test.s -g3 
-fdump-rtl-final -O0` on aarch64.

#include <string.h>
#include <stdio.h>
int main (int argc, char *argv[]) {
         char buf[64];
         return !strcpy (buf, strrchr (argv[0], '/'));
}


Is there any tight meaning to NOTE_INSN_FUNCTION_BEG?

I'm wondering whether it should be split into one note to determine for 
the debugging use and another for the use in alias.c.

Regards,
Matthew

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Jeff Law]

On 1/4/19 9:03 AM, Matthew Malcomson wrote:
> Hi there,
> 
> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and 
> hoping someone here knows.
It doesn't mean very much anymore.   I believe it was used to
distinguish between stuff like copying incoming arguments into pseudos
and real user code.

However, in a world with instruction scheduling and other code motion it
just doesn't have much use because it's so imprecise, particularly as we
get deeper into the RTL pipeline.

> 
> The gcc internal documentation says it "Appears at the start of the 
> function body, after the function prologue." but this isn't very 
> precise, and it seems to not distinguish between the undocumented 
> NOTE_INSN_PROLOGUE_END and the NOTE_INSN_FUNCTION_BEG.
> 
> A comment in dwarf2out.c shows it's used as a marker between boilerplate 
> and code corresponding to things "the user wrote".
> This assumption is broken by things like -fstack-protector-strong (as 
> bugzilla 88432 shows).
That was the intent, but I think it's a concept that's fundamentally
flawed through much of the RTL pipeline these days.

> 
> alias.c seems to use it to assume that argument registers have their 
> original values before it (see the use of the "copying_arguments" 
> variable and find_base_value function).
> I'm not yet certain of this, but if that is the assumption I think this 
> is also not observed.
> 
> The test file below compiles to something breaking that assumption when 
> compiled with `gcc -fsanitize=address -S test.c -o test.s -g3 
> -fdump-rtl-final -O0` on aarch64.
> 
> #include <string.h>
> #include <stdio.h>
> int main (int argc, char *argv[]) {
>          char buf[64];
>          return !strcpy (buf, strrchr (argv[0], '/'));
> }
> 
> 
> Is there any tight meaning to NOTE_INSN_FUNCTION_BEG?
> 
> I'm wondering whether it should be split into one note to determine for 
> the debugging use and another for the use in alias.c.
Well, the question I'd ask is precisely what are you trying to mark?

Jeff

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

Hi Jeff,

On 30/04/19 16:29, Jeff Law wrote:
> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>> Hi there,
>>
>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>> hoping someone here knows.
> It doesn't mean very much anymore.   I believe it was used to
> distinguish between stuff like copying incoming arguments into pseudos
> and real user code.
> 
> However, in a world with instruction scheduling and other code motion it
> just doesn't have much use because it's so imprecise, particularly as we
> get deeper into the RTL pipeline.
> 

Ah, I guess an imprecise marker probably needs an imprecise definition ;-)

>>
> Well, the question I'd ask is precisely what are you trying to mark?


I'm wanting to mark the first instruction from "user code".
I'm trying to fix PR88432, where gdb puts the breakpoint from the 
"start" command in the wrong place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432

Gdb breaks on the second debug line entry in a function, which in 
practice is the instruction directly after NOTE_INSN_FUNCTION_BEG.


The "fuzzy" definition from gccint.info didn't seem to explain what was 
to happen with compiler inserted code that was not part of the prologue, 
and this was what I was hoping to nail down.

When looking, it seemed the note was being used in three slightly 
different ways (I went into more information in the cover letter of my 
[RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ), 
and I was hoping to get a precise definition so I could decide what 
approach to take.



Thanks,
MM


> 
> Jeff
> 

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Jeff Law]

On 4/30/19 10:48 AM, Matthew Malcomson wrote:
> Hi Jeff,
> 
> On 30/04/19 16:29, Jeff Law wrote:
>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>>> Hi there,
>>>
>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>>> hoping someone here knows.
>> It doesn't mean very much anymore.   I believe it was used to
>> distinguish between stuff like copying incoming arguments into pseudos
>> and real user code.
>>
>> However, in a world with instruction scheduling and other code motion it
>> just doesn't have much use because it's so imprecise, particularly as we
>> get deeper into the RTL pipeline.
>>
> 
> Ah, I guess an imprecise marker probably needs an imprecise definition ;-)
> 
>>>
>> Well, the question I'd ask is precisely what are you trying to mark?
> 
> 
> I'm wanting to mark the first instruction from "user code".
> I'm trying to fix PR88432, where gdb puts the breakpoint from the 
> "start" command in the wrong place.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
> 
> Gdb breaks on the second debug line entry in a function, which in 
> practice is the instruction directly after NOTE_INSN_FUNCTION_BEG.
> 
> 
> The "fuzzy" definition from gccint.info didn't seem to explain what was 
> to happen with compiler inserted code that was not part of the prologue, 
> and this was what I was hoping to nail down.
> 
> When looking, it seemed the note was being used in three slightly 
> different ways (I went into more information in the cover letter of my 
> [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ), 
> and I was hoping to get a precise definition so I could decide what 
> approach to take.
ISTM that we should place the stack protector bits before the
NOTE_INSN_FUNCTION_BEG.  At least in the non-optimizing compile case
that should make the right thing happen.

Jeff

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

On 30/04/19 18:01, Jeff Law wrote:
> On 4/30/19 10:48 AM, Matthew Malcomson wrote:
>> Hi Jeff,
>>
>> On 30/04/19 16:29, Jeff Law wrote:
>>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>>>> Hi there,
>>>>
>>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>>>> hoping someone here knows.
>>> It doesn't mean very much anymore.   I believe it was used to
>>> distinguish between stuff like copying incoming arguments into pseudos
>>> and real user code.
>>>
>>> However, in a world with instruction scheduling and other code motion it
>>> just doesn't have much use because it's so imprecise, particularly as we
>>> get deeper into the RTL pipeline.
>>>
>>
>> Ah, I guess an imprecise marker probably needs an imprecise definition ;-)
>>
>>>>
>>> Well, the question I'd ask is precisely what are you trying to mark?
>>
>>
>> I'm wanting to mark the first instruction from "user code".
>> I'm trying to fix PR88432, where gdb puts the breakpoint from the
>> "start" command in the wrong place.
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
>>
>> Gdb breaks on the second debug line entry in a function, which in
>> practice is the instruction directly after NOTE_INSN_FUNCTION_BEG.
>>
>>
>> The "fuzzy" definition from gccint.info didn't seem to explain what was
>> to happen with compiler inserted code that was not part of the prologue,
>> and this was what I was hoping to nail down.
>>
>> When looking, it seemed the note was being used in three slightly
>> different ways (I went into more information in the cover letter of my
>> [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ),
>> and I was hoping to get a precise definition so I could decide what
>> approach to take.
> ISTM that we should place the stack protector bits before the
> NOTE_INSN_FUNCTION_BEG.  At least in the non-optimizing compile case
> that should make the right thing happen.
> 
> Jeff
> 

Yeah, unfortunately I saw that moving that note would break some other 
places -- where the note is used as a marker for where to insert some 
other code.

The one I can remember (sort of) was that asan stack protection code is 
inserted just before "parm_birth_insn" (which is 
NOTE_INSN_FUNCTION_BEG), and that needs to be done before the non-local 
goto save area as per the solution for bugzilla 88186.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186

That was why I ended up suggesting multiple notes -- it's currently 
trying to satisfy more than one criteria and they're not quite compatible.


MM

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Jeff Law]

On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> On 30/04/19 18:01, Jeff Law wrote:
>> On 4/30/19 10:48 AM, Matthew Malcomson wrote:
>>> Hi Jeff,
>>>
>>> On 30/04/19 16:29, Jeff Law wrote:
>>>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>>>>> Hi there,
>>>>>
>>>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>>>>> hoping someone here knows.
>>>> It doesn't mean very much anymore.   I believe it was used to
>>>> distinguish between stuff like copying incoming arguments into pseudos
>>>> and real user code.
>>>>
>>>> However, in a world with instruction scheduling and other code motion it
>>>> just doesn't have much use because it's so imprecise, particularly as we
>>>> get deeper into the RTL pipeline.
>>>>
>>>
>>> Ah, I guess an imprecise marker probably needs an imprecise definition ;-)
>>>
>>>>>
>>>> Well, the question I'd ask is precisely what are you trying to mark?
>>>
>>>
>>> I'm wanting to mark the first instruction from "user code".
>>> I'm trying to fix PR88432, where gdb puts the breakpoint from the
>>> "start" command in the wrong place.
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
>>>
>>> Gdb breaks on the second debug line entry in a function, which in
>>> practice is the instruction directly after NOTE_INSN_FUNCTION_BEG.
>>>
>>>
>>> The "fuzzy" definition from gccint.info didn't seem to explain what was
>>> to happen with compiler inserted code that was not part of the prologue,
>>> and this was what I was hoping to nail down.
>>>
>>> When looking, it seemed the note was being used in three slightly
>>> different ways (I went into more information in the cover letter of my
>>> [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ),
>>> and I was hoping to get a precise definition so I could decide what
>>> approach to take.
>> ISTM that we should place the stack protector bits before the
>> NOTE_INSN_FUNCTION_BEG.  At least in the non-optimizing compile case
>> that should make the right thing happen.
>>
>> Jeff
>>
> 
> Yeah, unfortunately I saw that moving that note would break some other 
> places -- where the note is used as a marker for where to insert some 
> other code.
> 
> The one I can remember (sort of) was that asan stack protection code is 
> inserted just before "parm_birth_insn" (which is 
> NOTE_INSN_FUNCTION_BEG), and that needs to be done before the non-local 
> goto save area as per the solution for bugzilla 88186.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186
> 
> That was why I ended up suggesting multiple notes -- it's currently 
> trying to satisfy more than one criteria and they're not quite compatible.
Well, we obviously have to keep arg setup, asan, stack protector and
nonlocal stuff in the same relative order, but I believe they should all
ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
to make that happen :-)


> 
> 
> MM
> 

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

On 30/04/19 22:48, Jeff Law wrote:
> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
>> On 30/04/19 18:01, Jeff Law wrote:
>>> On 4/30/19 10:48 AM, Matthew Malcomson wrote:
>>>> Hi Jeff,
>>>>
>>>> On 30/04/19 16:29, Jeff Law wrote:
>>>>> On 1/4/19 9:03 AM, Matthew Malcomson wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and
>>>>>> hoping someone here knows.
>>>>> It doesn't mean very much anymore.   I believe it was used to
>>>>> distinguish between stuff like copying incoming arguments into pseudos
>>>>> and real user code.
>>>>>
>>>>> However, in a world with instruction scheduling and other code motion it
>>>>> just doesn't have much use because it's so imprecise, particularly as we
>>>>> get deeper into the RTL pipeline.
>>>>>
>>>>
>>>> Ah, I guess an imprecise marker probably needs an imprecise definition ;-)
>>>>
>>>>>>
>>>>> Well, the question I'd ask is precisely what are you trying to mark?
>>>>
>>>>
>>>> I'm wanting to mark the first instruction from "user code".
>>>> I'm trying to fix PR88432, where gdb puts the breakpoint from the
>>>> "start" command in the wrong place.
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
>>>>
>>>> Gdb breaks on the second debug line entry in a function, which in
>>>> practice is the instruction directly after NOTE_INSN_FUNCTION_BEG.
>>>>
>>>>
>>>> The "fuzzy" definition from gccint.info didn't seem to explain what was
>>>> to happen with compiler inserted code that was not part of the prologue,
>>>> and this was what I was hoping to nail down.
>>>>
>>>> When looking, it seemed the note was being used in three slightly
>>>> different ways (I went into more information in the cover letter of my
>>>> [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ),
>>>> and I was hoping to get a precise definition so I could decide what
>>>> approach to take.
>>> ISTM that we should place the stack protector bits before the
>>> NOTE_INSN_FUNCTION_BEG.  At least in the non-optimizing compile case
>>> that should make the right thing happen.
>>>
>>> Jeff
>>>
>>
>> Yeah, unfortunately I saw that moving that note would break some other
>> places -- where the note is used as a marker for where to insert some
>> other code.
>>
>> The one I can remember (sort of) was that asan stack protection code is
>> inserted just before "parm_birth_insn" (which is
>> NOTE_INSN_FUNCTION_BEG), and that needs to be done before the non-local
>> goto save area as per the solution for bugzilla 88186.
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186
>>
>> That was why I ended up suggesting multiple notes -- it's currently
>> trying to satisfy more than one criteria and they're not quite compatible.
> Well, we obviously have to keep arg setup, asan, stack protector and
> nonlocal stuff in the same relative order, but I believe they should all
> ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
> to make that happen :-)
> 

It's pretty easy if we can replace the uses of NOTE_INSN_FUNCTION_BEG 
with another note:

In order to satisfy how it's used in `final_start_function_1`, 
`sjlj_emit_function_enter` in except.c and the nonlocal stuff I could 
add a differently named note at the current position.

Then I could move NOTE_INSN_FUNCTION_BEG to after everything 
automatically added since it's then only used by the debug information.

How would you feel about a modification of my RFC patch
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ,
where the uses of the suggested NOTE_INSN_DEBUG_FUNCTION_BEG are 
satisfied by NOTE_INSN_FUNCTION_BEG and a new NOTE_INSN_VAR_END where 
the current NOTE_INSN_FUNCTION_BEG is?

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Segher Boessenkool]

On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> > That was why I ended up suggesting multiple notes -- it's currently 
> > trying to satisfy more than one criteria and they're not quite compatible.
> Well, we obviously have to keep arg setup, asan, stack protector and
> nonlocal stuff in the same relative order, but I believe they should all
> ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
> to make that happen :-)

The current meaning of NOTE_INSN_FUNCTION_BEG is

  /* Indicate the beginning of the function body,
     as opposed to parm setup.  */
  emit_note (NOTE_INSN_FUNCTION_BEG);

(function.c), and half of the things that use the note think that
everything before it is argument setup, and nothing after it is.

Just adding extra notes isn't enough afaics; some surgery is needed.


Segher

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

On 01/05/19 20:40, Segher Boessenkool wrote:
> On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
>> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
>>> That was why I ended up suggesting multiple notes -- it's currently
>>> trying to satisfy more than one criteria and they're not quite compatible.
>> Well, we obviously have to keep arg setup, asan, stack protector and
>> nonlocal stuff in the same relative order, but I believe they should all
>> ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
>> to make that happen :-)
> 
> The current meaning of NOTE_INSN_FUNCTION_BEG is
> 
>    /* Indicate the beginning of the function body,
>       as opposed to parm setup.  */
>    emit_note (NOTE_INSN_FUNCTION_BEG);
> 
> (function.c), and half of the things that use the note think that
> everything before it is argument setup, and nothing after it is.
> 
> Just adding extra notes isn't enough afaics; some surgery is needed.
> 
> 
> Segher
> 

Apologies, I don't follow -- could you elaborate on why an extra note is 
not enough?

If this note is trying to mark the end of the argument setup for those 
places you mention, and the start of user code for debug output, and 
those are not the same place then I would have thought splitting it 
would be necessary.

Do you mean that splitting would have to be followed by some extra work 
so the different uses would use the specific note they want?

MM

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Segher Boessenkool]

On Thu, May 02, 2019 at 01:02:14PM +0000, Matthew Malcomson wrote:
> On 01/05/19 20:40, Segher Boessenkool wrote:
> > On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
> >> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
> >>> That was why I ended up suggesting multiple notes -- it's currently
> >>> trying to satisfy more than one criteria and they're not quite compatible.
> >> Well, we obviously have to keep arg setup, asan, stack protector and
> >> nonlocal stuff in the same relative order, but I believe they should all
> >> ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
> >> to make that happen :-)
> > 
> > The current meaning of NOTE_INSN_FUNCTION_BEG is
> > 
> >    /* Indicate the beginning of the function body,
> >       as opposed to parm setup.  */
> >    emit_note (NOTE_INSN_FUNCTION_BEG);
> > 
> > (function.c), and half of the things that use the note think that
> > everything before it is argument setup, and nothing after it is.
> > 
> > Just adding extra notes isn't enough afaics; some surgery is needed.
> 
> Apologies, I don't follow -- could you elaborate on why an extra note is 
> not enough?
> 
> If this note is trying to mark the end of the argument setup for those 
> places you mention, and the start of user code for debug output, and 
> those are not the same place then I would have thought splitting it 
> would be necessary.

Because other things want to use it as the place to put stack checking,
for example.  And that cannot be after this note, but it can also not
be before it.

Is there any reason the stack checking code is inserted way before the
prologue/epilogue are, btw?


Segher

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Matthew Malcomson]

On 02/05/19 16:33, Segher Boessenkool wrote:
> On Thu, May 02, 2019 at 01:02:14PM +0000, Matthew Malcomson wrote:
>> On 01/05/19 20:40, Segher Boessenkool wrote:
>>> On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote:
>>>> On 4/30/19 11:24 AM, Matthew Malcomson wrote:
>>>>> That was why I ended up suggesting multiple notes -- it's currently
>>>>> trying to satisfy more than one criteria and they're not quite compatible.
>>>> Well, we obviously have to keep arg setup, asan, stack protector and
>>>> nonlocal stuff in the same relative order, but I believe they should all
>>>> ultimately land before the NOTE_INSN_FUNCTION_BEG.  THe question is how
>>>> to make that happen :-)
>>>
>>> The current meaning of NOTE_INSN_FUNCTION_BEG is
>>>
>>>     /* Indicate the beginning of the function body,
>>>        as opposed to parm setup.  */
>>>     emit_note (NOTE_INSN_FUNCTION_BEG);
>>>
>>> (function.c), and half of the things that use the note think that
>>> everything before it is argument setup, and nothing after it is.
>>>
>>> Just adding extra notes isn't enough afaics; some surgery is needed.
>>
>> Apologies, I don't follow -- could you elaborate on why an extra note is
>> not enough?
>>
>> If this note is trying to mark the end of the argument setup for those
>> places you mention, and the start of user code for debug output, and
>> those are not the same place then I would have thought splitting it
>> would be necessary.
> 
> Because other things want to use it as the place to put stack checking,
> for example.  And that cannot be after this note, but it can also not
> be before it.
> 

I figured the stack checking could be after one note (end of argument 
setup), and before the other (start of user code)?

> Is there any reason the stack checking code is inserted way before the
> prologue/epilogue are, btw?
> 

I don't know, I'm especially curious why the prologue & epilogue are 
emitted in assembly with the TARGET_ASM_FUNCTION_{EPILOGUE,PROLOGUE} 
macros instead of emitted as rtl somewhere earlier in the pipeline.

I'd guess the stack checking code is earlier since it would like to be 
optimised by the RTL passes.



Are you thinking there's call for a more thorough handling of the 
introduction and placement of these almost-prologue parts like 
stack-checking, non-local goto save areas and the like?

> 
> Segher
> 

Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?

[Segher Boessenkool]

On Fri, May 03, 2019 at 09:29:11AM +0000, Matthew Malcomson wrote:
> On 02/05/19 16:33, Segher Boessenkool wrote:
> > Because other things want to use it as the place to put stack checking,
> > for example.  And that cannot be after this note, but it can also not
> > be before it.
> > 
> 
> I figured the stack checking could be after one note (end of argument 
> setup), and before the other (start of user code)?

I don't think that can work.  It needs to do its thing before anything
else (that can overflow, at least) touches the stack.

> > Is there any reason the stack checking code is inserted way before the
> > prologue/epilogue are, btw?
> 
> I don't know, I'm especially curious why the prologue & epilogue are 
> emitted in assembly with the TARGET_ASM_FUNCTION_{EPILOGUE,PROLOGUE} 
> macros instead of emitted as rtl somewhere earlier in the pipeline.

They are emitted as RTL on most targets.  Some targets *also* use some
asm text output for special things, but the usual prologue code is done
as RTL.

> I'd guess the stack checking code is earlier since it would like to be 
> optimised by the RTL passes.

It cannot, or *should* not, be optimised much.  Hrm.

> Are you thinking there's call for a more thorough handling of the 
> introduction and placement of these almost-prologue parts like 
> stack-checking, non-local goto save areas and the like?

I think we should try to no longer rely on these magic notes, which only
still work by luck, or even do nbot really work anymore.


Segher