Re: Minor codegen silliness in ExecInterpExpr()

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
>> + * Note: the reason for using a temporary variable "d", here and in
>> + * other places, is that some compilers think "*op->resvalue = f();"
>> + * requires them to evaluate op->resvalue into a register before
>> + * calling f(), just in case f() is able to modify op->resvalue
>> + * somehow. The extra line of code can save a useless register spill
>> + * and reload, on architectures without many registers.

> I'd remove the "without many registers" bit - that's really more an
> functioncall ABI question (#caller vs #callee saved registers) than
> about the actual architecture.

Fair enough.

I wondered how pervasive this behavior is. AFAICS it is *not* required
by the C standard; C99 does not say that the left operand of assignment
must be evaluated first, in fact it says that the order of evaluation is
unspecified. But the latest gcc I have at hand (6.4.1 on Fedora 25) still
does it this way. OTOH, Apple's latest edition of clang (LLVM version
9.0.0 (clang-900.0.37)) appears to be just fine with waiting till after
the function call to load op->resvalue. So that's not many data points,
but it does suggest that this is worth fixing, and is not just an artifact
of an old compiler version.

regards, tom lane