Re: Andres Freund 2018-07-25 <20180725195037.jmykfzfporf6a...@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
