Re: Add support for the Win32 hook prologue (try 3)

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Pedro Alves wrote:

> (Since we're being so meticulous about nops, :-) ), a thought just
> crossed my mind: is there any optimization
> that could get rid of of a tail-call's jump if it happens that the
> callee is the function just after the caller in memory, thus making
> it so that the nops *have* to be some kind of nops, as they'd be
> executed while "falling-through"?

  Not in the compiler, because the compiler has to be pretty agnostic about
where things are going to actually end up in memory once the linker's got done
with them; but this could be implemented as a linker relaxation quite easily I
would have thought.  (It might be argued that the compiler could make
assumptions about successive functions emitted to the same section being
contiguous, e.g. when -ffunction-sections is not in effect, but I'd think even
that would be a fragile assumption - some assemblers and linkers might put
unexpected things like constant pools or intermediate branch trampolines in
between your functions.)

> Say, with func1 tail calling func2, you'd end up with:
> 
>  func1:
>   foo_insn
>   bar_insn
>   <no jump or ret>
>   nop  <alignment nop>
>  func2:
>   ...

  You'd want to be sure that executing the alignment nops was actually quicker
than just taking the jump, and disable the relaxation when not.

> I'm just curious about the practice of injecting code sort of
> behind the compiler's back using these target hooks.

  Well, in this case it's ok because it's outputting code before the start of
the function and it can't really affect anything, but in general yes, you need
to be careful; the compiler is going to be unaware of this code's existence.
Adding stuff at the very start of the prologue (before the scheduled RTL) is
also pretty safe.  But outputting code in any other target hook in the middle
of a function is likely to cause problems; at the very least, the compiler's
branch range calculations will be off and you may fool it into choosing a
short branch insn for a jump that your extra code pushes out of range.

    cheers,
      DaveK