Hi,
On 2018-07-25 21:39:26 +0200, Christoph Berg wrote:
> Re: Andres Freund 2018-07-25 <20180725191143.sietxlbfehv245hb@alap3.anarazel.de>
> > I haven't investigated the details here. It certainly would be possible
> > to have the _PG_init() of postgis's so force JIT to be off, and emit a
> > warning.
>
> Isn't that too late, if postgis.so gets loaded by a query that is in
> to process of being jit'ed?
Hm, I'd guess it'd still be fine, but I haven't thought it sufficiently
through.
> 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.
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 precisely would you want to test?
Greetings,
Andres Freund