On Thu, 28 Apr 2016, Richard Biener wrote: > Doing anything based on 'cfun' here is fishy at least for the > call context of aggregate_value_p as that is also used when > looking at the caller side of a call for example when expanding calls > where cfun is then the callers cfun and not the callees. > > So I suggest to remove cfun->machine->doing_call and revisit the > reason why it was added for PTX.
It does look a bit strange. My understanding is this: today, nvptx never returns aggregates on registers, so either an aggregate value is returned on stack, or a scalar value is returned on a register. The backend wants to record the RTL mode of the value being returned (hence the 'outgoing' check in nvptx_function_value), but otherwise wants to behave as if callees return values in a fixed register, but callers receive values in a pseudo register (hence the 'doing_call' check in nvptx_libcall_value: it can be called in a context when pseudos can't be generated, but if we aren't currently expanding a call to RTL, we can give whatever hard reg to middle end in the right mode; it's a hack). So if my understanding is correct, additional !cfun check can be acceptable as a fix along the existing hack. Perhaps with a note about the nature of the hack. Thanks. Alexander
