Re: Andres Freund 2018-07-25 <20180725195037.jmykfzfporf6auxn@alap3.anarazel.de>
> > Different question, the other way round, is there a way to know that
> > all files needed to inline a query/extension are there? How does the
> > JIT machinery determine it can (try to) compile things? (That's
> > something extension packages might want to test for.)
>
> I'm not 100% sure I understand your question. Let me describe how it
> works, and maybe you can then rephrase afterwards?
>
> 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?
> 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?
Christoph