[llvm-commits] [ARM] Scheduler FixedFrame object vs byval formal parameters

[Sergei Larin]

Stepan,

  Do you have an example that illustrates your issue? Sorry if you have
already send it before... Thanks.

Sergei

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

> -----Original Message-----
> From: Stepan Dyatkovskiy [mailto:stpworld at narod.ru]
> Sent: Monday, October 08, 2012 5:21 AM
> To: Manman Ren
> Cc: Sergei Larin; 'Bill Schmidt'; 'llvm-commits'
> Subject: Re: [llvm-commits] [ARM] Scheduler FixedFrame object vs byval
> formal parameters
> 
> Hello.
> Please find the patch in attachment. It adds two new fields to the
> InputArg structure: Function's argument index and InputArg's part
> offset in bytes relative to the start position of Function's argument.
> E.g.: If function's argument is 128 bit width and it was splitted onto
> 32bit regs, then we got 4 InputArg structs with same arg index, but
> different offset values.
> 
> I also modified ARMISelLowering, to fix wrong scheduling issue. The fix
> is similar to r164553, but it uses new InputArg fields.
> 
> -Stepan.
> 
> Manman Ren wrote:
> >
> > On Oct 5, 2012, at 2:59 AM, Stepan Dyatkovskiy <stpworld at narod.ru>
> wrote:
> >
> >> Thanks. The idea looks fine. But r164553 assumes that size of
> Function's arguments set is equal to size of InputArgs set:
> >> "for (unsigned ArgNo = 0, e = Ins.size(); ArgNo != e; ++ArgNo,
> ++FuncArg) {"
> >>
> >> But seems that it not always right. In
> SelectionDAGISel::LowerArguments we can see that Function argument be a
> set of multiple VTs, in that case multiple InputArg flags will be
> created for single argument. Try test your commit for complex params
> (structures or arrays).
> > I agree with you here. A function argument can be expanded to a set
> of VTs, and each VT can be further partitioned with
> TLI.getNumRegisters.
> >
> >>
> >> Perhaps, we can provide InputArg type with some info about
> Function's argument and offset?
> > I am okay with this approach, perhaps an index of the original
> function argument.
> >
> > Thanks,
> > Manman
> >
> >>
> >> -Stepan.
> >>
> >> Sergei Larin wrote:
> >>> Stepan,
> >>>
> >>>    ...also see r164553.
> >>>
> >>
> >