[llvm-commits] [ARM] Extra frame for non-VA byval parameter
manman ren
mren at apple.com
Thu Oct 18 10:47:02 PDT 2012
Hi Stepan,
Can you make sure that when you call VarArgsStyleRegisters for byval, the else clause of VarArgsStyleRegisters will create a mutable stack object?
} else
// This will point to the next argument passed via stack.
AFI->setVarArgsFrameIndex(MFI->CreateFixedObject(4, ArgOffset, true)); <-- true means immutable
I am concerned because of the comment here:
// FIXME: For now, all byval parameter objects are marked mutable.
// This can be changed with more analysis.
// In case of tail call optimization mark all arguments mutable.
// Since they could be overwritten by lowering of arguments in case of
// a tail call.
Thanks a lot!
Manman
On Oct 18, 2012, at 3:33 AM, Stepan Dyatkovskiy <stpworld at narod.ru> wrote:
> Hi Manman,
>
> manman ren wrote:
>>
>> On Oct 17, 2012, at 11:50 AM, Stepan Dyatkovskiy <stpworld at narod.ru> wrote:
>>
>>> We invoke VarArgsStyleRegisters for the first byval argument only. If I got right its memory part starts with ArgOffset = 0 always. I inserted assertion "VA.getLocMemOffset() == 0" at the beginning of this branch just for belaying.
>>> Though is there any hypotetical cases where it may fail?
>> What if we have lots of scalars before the first byval argument such that the first byval argument will not start at offset 0?
>> VARegSaveSize will probably be zero for that case, and we will fall to the else clause in VarArgsStyleRegisters.
> Of course, it couses improper behaviour. I fixed patch and reattached it.
> -Stepan.
>
> <byval-frame-fix.patch>
More information about the llvm-commits
mailing list