dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.96k stars 4.65k forks source link

Unix: For calls that return structs, codegen should take advantage of the fact that the address is returned in RAX. #4903

Open CarolEidt opened 8 years ago

CarolEidt commented 8 years ago

This affects both the lowering and the code generation for calls. For UNIX AMD64, we should not be allocating a return register for struct returns that are on stack. For the SIMD case, however, we do want a "return register", as the consumer of the call will want the value in a register. Currently it is always allocating REG_FLOATRET, but we should flexibly allocate this register as it need not be the designated floating point return register (e.g. it could be preferenced to the target of a store). See the GT_CALL case in TreeNodeInfoInit() in lowerxarch.cpp and genCallInstruction() in codegenxarch.cpp.

category:cq theme:calling-convention skill-level:intermediate cost:medium impact:medium

CarolEidt commented 8 years ago

Correction: After consulting the ABI doc, I realized that it requires that the struct address be returned to the caller in RAX. As it happens, our codegen is not taking advantage of that, but is instead using the value that it passed in (which has often been saved on the stack). So, the title of this issue has been changed to make that clear. This will require finding a way to model the fact that, after a call, RAX contains an address of a local, and I don't think we currently handle anything quite like that. For SIMD types, taking advantage of the returned address in RAX will require a bit more finesse in register allocation, as the caller's expression will be expecting the value in a SIMD register.