[llvm-commits] [ARM] Extra frame for non-VA byval parameter

[Stepan Dyatkovskiy]

Hi Manman,
Now I understood what you mean in your previous post. That was big 
omission from my side.

Of course, when we have no regs for byval param, we go to the else 
clause, and immutable stack object will created in this case. We need to 
get it making mutable objects. I propose to add one more parameter to 
VarArgsStyleRegisters "ForceMutable" that will control this behaviour.
Updated patch is in attachment.

P.S.: Perhaps VarArgsStyleRegisters should be renamed then. Since this 
method used as well in fixed arg function prologues.

-Stepan.
manman ren wrote:
>
> 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>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: byval-frame-fix.patch
Type: text/x-patch
Size: 4557 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/7bb19c0c/attachment.bin>