Horton

Re: WIP: expression evaluation improvements

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Soumyadeep Chakraborty <sochakraborty@pivotal.io>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-07T06:28:59Z
Lists: pgsql-hackers 
Hi,

On 2019-10-28 23:58:11 -0700, Soumyadeep Chakraborty wrote:
> > Cool! I'll probably merge that into my patch (with attribution of
> > course).
> >
> > I wonder if it'd nicer to not have separate C variables for all of
> > these, and instead look them up on-demand from the module loaded in
> > llvm_create_types(). Not sure.
> 
> Great! It is much nicer indeed. Attached version 2 with your suggested
> changes.
> (v2-0001-Rely-on-llvmjit_types-for-building-EvalFunc-calls.patch)
> Used the same testing method as above.

I've comitted a (somewhat evolved) version of this patch. I think it
really improves the code!

My changes largely were to get rid of the LLVMGetNamedFunction() added
to each opcode implementation, to also convert the ExecEval* functions
we were calling directly, to remove the other functions in llvmjit.h,
and finally to rebase it onto master, from the patch series in this
thread.

I do wonder about adding a variadic wrapper like the one introduced here
more widely, seems like it could simplify a number of places. If we then
redirected all function calls through a common wrapper, for LLVMBuildCall,
that also validated parameter count (and perhaps types), I think it'd be
easier to develop...

Thanks!

Andres

Commits

  1. Add special case fast-paths for strict functions

  2. Replace EEOP_DONE with special steps for return/no return

  3. jit: Reference expression step functions via llvmjit_types.

  4. jit: Remove redundancies in expression evaluation code generation.

  5. expression eval: Don't redundantly keep track of AggState.

  6. jit: Reference functions by name in IOCOERCE steps.

  7. expression eval, jit: Minor code cleanups.