[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