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

manman ren mren at apple.com
Thu Oct 18 13:18:48 PDT 2012


On Oct 18, 2012, at 12:15 PM, Stepan Dyatkovskiy <stpworld at narod.ru> wrote:

> 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.

LGTM
Feel free to rename VarArgsStyleRegisters since it is used for byval as well.

Thanks,
Manman

> 
> -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>
>> 
> 
> <byval-frame-fix.patch>




More information about the llvm-commits mailing list