RE: Feature request concerning opcodes in the function prolog

[Stefan Dösinger <stefan at codeweavers dot com>]

> You don't need to force the frame pointer on, it is sufficient to say
> that
> ebp needs restoring at the end of the function no matter if it looks
> otherwise
> used or not - and you have to take the frame size impact of the saved
> ebp into
> account.
How does this fit together with the stack realignment code? This is
something I am not sure with yet.

I am considering something like this pseudo code(not done with real coding
yet):

int setup_frame_pointer = frame_pointer_needed;

if(msvc_prolog)
{
    emit_insn(gen_movnop(%di)); /* mov %edi, %edi */
    emit_insn(gen_msvc_fp(%sp, %bp)); /* push %esp; mov %esp, %ebp */

    if(frame_pointer_needed && !( crtl->drap_reg &&
crtl->stack_realign_needed))
    {
        setup_frame_pointer = 0;
    }
    else
    {
        emit_insn(gen_revert_msvc_fp(%bp)); /* pop %ebp */
    }
}

/* ... */
stack realignment code here
/* ... */

if(setup_frame_pointer /* used to be frame_pointer_needed */) {
	/* Normal fp setup code */
}

Basically the idea is that if the frame pointer is set up there's this code
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
; frame pointer already set up, continue with normal code. Nice and pretty

If the frame pointer is not needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp	
; Continue normally here. I think that case can't be improved too much,
since the msvc_prolog stuff modifies the base pointer.

Now my problem: If the frame pointer is needed, and the stack realignment is
needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
leal ...
push %ebp
mov %esp, %ebp

This doesn't look pretty, really.

> Moreover, if your prologue beings with an unspec_volatile that emits
> the
> three-instruction sequence you want, the optimizers should leave it
> there
> at the start of the function.
> Although it is properly easiest to get debug and unwind information
> right
> if you make this three separate unspec_volatile patterns, with their
> respective REG_FRAME_RELATED_EXPR notes where applicable.
> I.e. the push ebp saves ebp and changes the stack.
> The mov.s esp,ebp needs a REG_FRAME_RELATED_EXPR note only if you are
> actually using a frame pointer.
The REG_FRAME_RELATED_EXPR is set with this, right: ?
RTX_FRAME_RELATED_P (insn) = 1;

I haven't yet figured out what it does exactly.

Another issue is 64 bit. I guess if I use the hard_frame_pointer_rtx,
stack_pointer_rtx and similar register indentifiers and pass it to the
gen_XXXX functions I should get proper code for both 32 and 64 bit, right?
Besides that I still have to look if Windows has such a hooking-friendly
function prologue on Win64 too, or if that is just a 32 bit issue.