[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