Hi,
On 2018-07-25 21:59:32 +0200, Christoph Berg wrote:
> Re: Andres Freund 2018-07-25 <20180725195037.jmykfzfporf6auxn@alap3.anarazel.de>
> > The way inlining works is that, when referencing a function, the bitcode
> > summary file corresponding to it (either postgres.index.bc if builtin or
> > $extension.index.bc if in an extension) gets opened. That contains
> > metadata (name, number of instructions, ...) about the functions
> > included in the indexed .bc files (which reside in
> > $module/path/to/$file.bc). Those .bc files in turn are generated by
> > clang -emit-llvm. The inlining machinery looks up functions in the
> > corresponding .index.bc, checks whether they are smaller than the
> > instruction limit, and inlines them if below.
>
> Is that top-level functions (SQL language "C" functions), or all
> C-code functions?
The "initial" entry point has to be a C (or INTERNAL) function. But
called function can recursively get inlined (with the size limit being
halved every recursion step). Outside of hooks etc there's no other way
to call extension functions outside of SQL level functions, so that's
not really a restriction.
> > If a function is not in the summary, or it is too large, it'll just
> > generate an external function call. It's perfectly normal to have too
> > large functions and functions that aren't present (e.g. random libraries
> > including libc).
>
> What happens if some (SQL) function is in there, but calls into a
> function that is not? Or is in a different index?
I'm not precisely sure what you mean. You're thinking of a C UDF that's
calling a C function (not a UDF) that's not in the index? If so, then
we'll just not inline that inner function, but generate a normal
function call (i.e. on asm level that'll be a callq instruction or
whatever your platform wants to do).
Greetings,
Andres Freund