<div dir="ltr">Hi,<div><br></div><div>This information is mostly for GlobalISel developers. I'd like to make a couple of suggestions about the process of lowering of function arguments / return values. I've heard that GlobalISel is developing rapidly, maybe it is not too late to make little changes to the API.</div><div><br></div><div>Although GlobalISel has different interface compared to SelectionDAGISel, the approach to lowering function arguments / return values is essentially the same. Below I describe SelectionDAGISel, which I'm more familiar with.</div><div><br></div><div><font face="arial, sans-serif">Targets implement function argument / return value lowering by implementing </font><font face="monospace">LowerFormalArguments</font> and <span style="font-family:monospace">LowerReturn</span><font face="arial, sans-serif">, each of which does two things:</font></div><div>- associates a function argument (or return value) with some location, which may be a register or a position in the stack;<br></div><div>- emits some SDNodes to load arguments from (store return values to) the associated locations.</div><div><br></div><div><font face="monospace">LowerFormalArguments</font> is called before processing the function body, and <font face="monospace">LowerReturn</font> is called during lowering the function body. I.e. high level process of lowering arguments / return value looks like this:</div><div>- figure out locations for function arguments;</div><div>- emit some code to load the arguments out of their locations;</div><div>- lower some basic blocks;</div><div>- figure out locations for the return value;<br></div><div>- emit some code to store the return value to its location.</div><div><br></div><div>The last two steps are repeated for every <font face="monospace">ret</font> instruction encountered.</div><div><br></div><div>While this works in most cases, this approach has notable flaws:</div><div><ol><li>While lowering the function body in general (and lowering <font face="monospace">ret</font> instruction in particular), information about function argument locations is already lost. Some targets wish to have this information. In order to overcome this, they add variables to <font face="monospace">MachineFunctionInfo</font>, set them in <font face="monospace">LowerFunctionArguments</font> and query while lowering the body. It seems to me that <font face="monospace">MachineFunctionInfo</font> is not the best place for such things, as this kind of information is only needed for the instruction selection process. It should not survive to later passes.</li><li>Similarly, <font face="monospace">LowerFunctionArguments</font> does not have information about return value location, and there is no straightforward way to overcome this. A target may want to know how the return value is returned in order to properly generate function entry code.</li><li><font face="monospace">LowerReturn</font> is called for each <font face="monospace">ret</font> instruction, repeating the job of analyzing the return value every time.</li></ol><div>A few examples:</div></div><div>- most targets save information about vararg starting location to <font face="monospace">MachineFrameInfo</font> and use it in lowering <font face="monospace">VASTART</font> and similar;</div><div>- many targets save SRet virtual register as well;</div><div>- XCore backend stores <font face="monospace">ReturnStackOffset</font> to use in <font face="monospace">LowerReturn</font>;</div><div>- X86 and M68k targets save <font face="monospace">BytesToPopOnReturn</font> to use in <font face="monospace">LowerReturn</font>.</div><div>These are just a few random picks, there are more.</div><div><br></div><div>I would suggest two changes to the current approach:</div><div>- Extract the analysis part of <font face="monospace">LowerFormalArguments</font> and <font face="monospace">LowerReturn</font> to a common function (say, <font face="monospace">AnalyzeFunctionPrototype</font>). It will be responsible for choosing locations for the arguments <i>and</i> the return value only (no code generated). Typically, this new function will only contain calls to <font face="monospace">CCState::AnalyzeFormalArguments</font> <i>and</i> <font face="monospace">CCState::AnalyzeReturn</font><font face="arial, sans-serif">, saving </font><font face="monospace">CCValAssign</font><font face="arial, sans-serif"> instances and target-dependent information (see examples above) for later use.</font></div><div>- This new function will need to save the result of analysis somewhere to be available in <font face="monospace">LowerOperation</font><font face="arial, sans-serif">,</font> <font face="monospace">LowerReturn</font><font face="arial, sans-serif">, and others</font>. So, let the targets maintain a state of the currently lowered function. One possible (and most obvious) way to do this is to allow targets to inherit from existing <font face="monospace">FunctionLoweringInfo</font>.</div><div><br></div><div>With the suggested changes, the high level process will change to:</div><div><div>- figure out locations for function arguments <i>and</i> return values, save this information for later use;</div><div>- lower some basic blocks (analysis results should also be available for use);</div><div>- emit some code to load the arguments out of their locations using the results of the earlier analysis;</div><div>- emit some code to store the return value to its location using the results of the earlier analysis.</div></div><div><br></div><div>//</div><div>Sorry for my English</div><div><br></div></div>