Re: Special-case executor expression steps for common combinations

> On 12 Oct 2023, at 19:52, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-10-12 13:24:27 +0300, Heikki Linnakangas wrote:
>> On 12/10/2023 12:48, Daniel Gustafsson wrote:

>>> The attached patch adds special-case expression steps for common sets of steps
>>> in the executor to shave a few cycles off during execution, and make the JIT
>>> generated code simpler.
>>>
>>> * Adds EEOP_FUNCEXPR_STRICT_1 and EEOP_FUNCEXPR_STRICT_2 for function calls of
>>> strict functions with 1 or 2 arguments (EEOP_FUNCEXPR_STRICT remains used for
>>>> 2 arguments).
>>> * Adds EEOP_AGG_STRICT_INPUT_CHECK_ARGS_1 which is a special case for the
>>> common case of one arg aggs.
>>
>> Are these relevant when JITting? I'm a little sad if the JIT compiler cannot
>> unroll these on its own. Is there something we could do to hint it, so that
>> it could treat the number of arguments as a constant?
>
> I think it's mainly important for interpreted execution.

Agreed.

>>> skip extra setup for steps which are only interested in the side effects.
>>
>> I'm a little surprised if this makes a measurable performance difference,
>> but sure, why not. It seems nice to be more explicit when you don't expect a
>> return value.

Right, performance benefits aside it does improve readability IMHO.

> IIRC this is more interesting for JIT than the above, because it allows LLVM
> to know that the return value isn't needed and thus doesn't need to be
> computed.

Correct, this is important to the JIT code which no longer has to perform two
Loads and one Store in order to get nothing, but can instead fastpath to
building a zero returnvalue.

--
Daniel Gustafsson