[llvm-commits] sret-demotion for large struct returns working on x86!

[Kenneth Uildriks]

On Mon, Nov 9, 2009 at 10:32 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Kenneth,
>
>> +  // True if the function needs to be sret-demoted
>> +  bool CantLowerReturn;
>
> rather than using a negative, how about CanLowerReturn?

I had the notion that we usually tried to default flags to false.

>
>> +  /// getCantLowerReturn - Return true if the function needs
>> sret-demotion.
>
> The name exposes the implementation (accessing an internal variable called
> CantLowerReturn) rather than the logical function.  How about negating it
> and
> calling it "canLowerReturn".

Excellent idea.  I'll do that.

>
>> +  bool CanLowerReturn = TLI.CanLowerReturn(CS.getCallingConv(), +
>>                FTy->isVarArg(), OutVTs, OutsFlags, DAG);
>
> Isn't it confusing to have several Can/Cant's.  What's the connection
> between
> them?

TargetLowering::CanLowerReturn checks lowerability against the target
implementation of the calling convention.  In
SelectionDAGISel::LowerArguments, I'm calling
TargetLowering::CanLowerReturn once, then stashing that information
(along with a virtual reg to hold the inserted sret parameter, if
CanLowerReturn returns false) in the MachineFunction (the
CantLowerReturn flag and the DemoteRegister field) so I don't have to
keep calling CanLowerReturn each time I hit a return instruction
(handled by SelectionDAGLowering::visitRet) in that same function.

I'm assuming, of course, that (a) LowerFormalArguments always gets
called before visitRet and (b) the same MachineFunction instance
always comes back whenever visitXXX or LowerXXX is called to process
code within the same function.  If either assumption is bogus, then my
code is broken.