On 11 March 2012 18:50, Robert Jacques <[email protected]> wrote: > On Sun, 11 Mar 2012 05:57:05 -0500, Manu <[email protected]> wrote: > > On 11 March 2012 04:35, Sean Cavanaugh <[email protected]> >> wrote: >> >> On 3/10/2012 8:08 PM, Mantis wrote: >>> >>> Tuple!(float, float) callee() { >>>> do something to achieve result in st0,st1 >>>> fst st0, st1 into stack >>>> load stack values into EAX, EDX >>>> ret >>>> } >>>> >>>> void caller() { >>>> call callee() >>>> push EAX, EDX into a stack >>>> fld stack values into st0, st1 >>>> do something with st0, st1 >>>> } >>>> >>>> As opposed to: >>>> >>>> Tuple!(float, float) callee() { >>>> do something to achieve result in st0,st1 >>>> ret >>>> } >>>> >>>> void caller() { >>>> call callee() >>>> do something with st0, st1 >>>> } >>>> >>>> Is there something I miss here? >>>> >>>> >>> Yes, the fact the FPU stack is deprecated :) >>> >>> >> Don't dismiss the point, the same still stands true with XMM regs. >> >> > And Walter has talked about using the XMM registers to return floating > point data for exactly this reason. But those optimization apply to all > structs and all data types. There's nothing special about MRV. It has to > return a set of data in a structured manner; this is identical to the case > of returning a struct. >
Well you can't build these sorts of tightly packed structs in XMM registers... and even for the GPR's, it's very inefficient to do so. I haven't done tests, but I suspect this feature is probably a de-optimisation in all cases other than an int-pair struct (ranges, delegates? I suspect that's why this was invented). Structure packing/unpacking code will likely be slower than a store/load. We just need proper multiple return values, then this can go away. And the earlier any ABI breaking changes are implemented, the better, while there are still few(/none?) closed source, binary distributed D libraries.
