Quoting Stefan Dösinger <ste...@codeweavers.com>:
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.
If ebp needs to be saved because it contains a user variable, it is better
not to pop it in the prologue - pop it in the epilogue instead, and you don't
need to have another save/restore.
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 can be done with much shorter assembly, at the cost of a bit more
logic in your prologue / epilogue expanders:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
leal ... (adjust value to account for the ebp stack slot)
and in the epilogue, after restoring the stack to what it was prior to
re-aligning, you do:
pop %ebp
The REG_FRAME_RELATED_EXPR is set with this, right: ?
RTX_FRAME_RELATED_P (insn) = 1;
No, REG_FRAME_RELATED_EXPR is a special kind of note for when the dwarf /
unwind code can't figure out the information from the pattern of the
instruction. Looking at dwarf2out2.c:dwarf2out_frame_debug_expr ,
I see that you should be able to use a PARALLEL with one part being the
operation actually performed, and another part an UNSPEC_VOLATILE to
prevent unwanted code motion / deletion etc.
When RTX_FRAME_RELATED_P is set on an insn,
I haven't yet figured out what it does exactly.
When RTX_FRAME_RELATED_P is set on an insn, dwarf call frame information
and exception unwinding information will be generated for this instruction
(if this kind of information is generated for this translation unit).
If REG_FRAME_RELATED_EXPR, this specifies the cfi information for this
instruction; otherwise, dwarf2out_frame_debug_expr will analyze the
PATTERN
of the instruction itself.
