[llvm-commits] [ARM] Extra frame for non-VA byval parameter
Stepan Dyatkovskiy
stpworld at narod.ru
Wed Oct 17 04:23:20 PDT 2012
Hi Manman,
Yesterday Saleem Abdulrasool created PR14099 that is demonstrates issue
described in this thread.
Below I try to explain, what happens in PR14099.
BTW, note, VarArgStyleRegisters should be invoked the only time for each
function prologue. This restriction is not satisfied if we have N byval
fixed args.
OK. Assume we have the only fixed byval argument.
For fixed frame argument first stack frame (for registers) is created
always in the beginning of arguments area (VarArgStyleRegisters invoked
with ArgOffset == 0). Second stack frame is created with ArgOffset == 0,
since it is first byval argument. Though the end of data is truncated by
size of head stored in regs :-)
Data restoring approach suppose next: registers data should be saved in
area, that is *attached* to the memory area:
(you need fixed width fonts here)
| [Initial SP points to mem area start]
V
[r0, r1, r2, ... ][memory area]
That works fine for VA functions. For fixed args function
current implementation brokes this approach.
PR14099 demonstrates that:
If 3 regs are used we still have 16 bytes stack area for registers (in
EABI mode stack has 8 bytes alignment), but stack frame for regs is
created with 4 bytes offset. "second" stack frame for memory data is
still created with 0 bytes offset (since it knows nothing about byval
regs). And we got the next stack frames:
[Saved regs area]| | [Initial SP value]
| V
V [remained data stored by caller]
<4 dummy bytes> [r1, r2, r3]
[ memory stack frame ............................] <truncated>
Of course we got broken date if we will read it from memory stack frame.
We should generate at least the next one:
[Saved regs area]| | [Initial SP value]
| V
V [remained data stored by caller]
<4 dummy bytes> [r1, r2, r3]
[ memory stack frame.......... ] <truncated>
Note, truncation matters nothing here. Only SP offset is important. For
VA functions in case where there are no regs available, only 4-bytes
sized stack frame is created.
I still propose to combine regs and memory stack frames. It is already
combined for VA functions, I propose to unify behaviour and to combine
frames for fixed args functions too. Note this behaviour is unified for
callers.
It should solve issues described in this thread and PR14099.
Please find updated patch in attachment.
-Stepan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: byval-frame-fix.patch
Type: text/x-patch
Size: 2026 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121017/760439b8/attachment.bin>
More information about the llvm-commits
mailing list