Re: meson vs. llvm bitcode files

Hi,

Thanks for looking into this!

On Mon, 6 Apr 2026 at 23:09, Andres Freund <andres@anarazel.de> wrote:
>
> On 2026-03-26 14:27:15 +0300, Nazir Bilal Yavuz wrote:
> > From ca280ffa86c4b4804ce517414c7aae015d6d21ea Mon Sep 17 00:00:00 2001
> > From: Andres Freund <andres@anarazel.de>
> > Date: Sat, 27 Aug 2022 09:52:03 -0700
> > Subject: [PATCH v12 1/7] meson: Add postgresql-extension.pc for building
> >  extension libraries
>
> I don't think we have enough agreement for this with a name as general as this
> yet.  What if we just have a postgresql-llvm-jit-bitcode or
> postgresql-$version-llvm-jit-bitcode for now?

Renamed to 'postgresql-$version-llvm-jit-bitcode'.


> Then we also don't need the tests and the autoconf parts yet.

These patches are removed.


> > Subject: [PATCH v12 4/7] meson: Add architecture for LLVM bitcode emission
>
> > +foreach bitcode_module : bitcode_modules
> > +  bitcode_targets = []
> > +  bitcode_obj = bitcode_module['target']
> > +  bitcode_cflags_local = bitcode_cflags + bitcode_module.get('additional_flags', [])
> > +  bitcode_name = bitcode_module.get('name', bitcode_obj.name())
> > +
> > +  foreach srcfile : bitcode_module['srcfiles']
> > +    if meson.version().version_compare('>=0.59')
> > +      srcfilename = fs.parent(srcfile) / fs.name(srcfile)
> > +    else
> > +      srcfilename = '@0@'.format(srcfile)
> > +    endif
> > +
> > +    targetname = '@0@_@1@.bc'.format(
> > +      bitcode_name,
> > +      srcfilename.underscorify(),
> > +    )
> > +    bitcode_targets += custom_target(
> > +      targetname,
> > +      depends: [generated_backend_headers_stamp],
>
> One thing that's quite annoying about the dependencies is that somehow this
> makes meson a lot slower generating build.ninja.  It takes 22s for me with the
> depend present, 5.1s without.
>
> One thing that seems to be fast, but is also somewhat ugly, is to use no
> depends but
>       input: [srcfile, bitcode_obj.extract_objects(srcfile)],
>
> That works because llvm_irgen_command just uses '@INPUT0@', but still adds a
> dependency to the .o file, which in turn has the right dependencies.
>
> While a bit gross, it still seems far better than 4x ing the build.ninja
> generation time.

I am able to reproduce it, done.


> > +  # Process generated sources, which may include custom compilation flags.
> > +  foreach gen_sources: bitcode_module.get('gen_sources', [])
>
> Are there actually cases where it makes sense to generate bitcode for these?
> I'm a bit doubtful.

Removed, this is not needed for the libraries you mentioned below.


> > From a4559525c8e9fa2999bf1d151dfe17bb83dc50f7 Mon Sep 17 00:00:00 2001
> > From: Nazir Bilal Yavuz <byavuz81@gmail.com>
> > Date: Mon, 16 Mar 2026 18:15:59 +0300
> > Subject: [PATCH v12 5/7] meson: Add LLVM bitcode emissions for contrib
> >  libraries
> >
> > The libraries which the bitcode files will be generated in are selected
> > manually.
> >
> > Author: Andres Freund <andres@anarazel.de>
> > Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
> > Author: Diego Fronza <diego.fronza@percona.com>
> > Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
> > Reviewed-by: Diego Fronza <diego.fronza@percona.com>
> > Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
> > Discussion: https://postgr.es/m/206b001d-1884-4081-bd02-bed5c92f02ba%40eisentraut.org
> > ---
...
>
> I think for most of these don't make much sense to generate bitcode.  I'd
> probably restrict it to hstore, citext, intarray, ltree, pg_trgm or
> such. There need to have lightweight SQL operators / functions to be
> considered for inlining, and that's just not the usecase most of these have.

Done, only 'hstore, citext, intarray, ltree and pg_trgm' are inlined for now.


> > From aa64b9ffc2b6aed9057568d616ab9e6c43af4b16 Mon Sep 17 00:00:00 2001
> > From: Nazir Bilal Yavuz <byavuz81@gmail.com>
> > Date: Wed, 12 Mar 2025 10:44:46 +0300
> > Subject: [PATCH v12 6/7] meson: Add LLVM bitcode emission for backend sources
> >
> > Since generated backend sources may have their own compilation flags and
> > must also be included in the postgres.index.bc, the way to make it work
> > with current code was to create a new variable, called
> > `bc_generated_backend_sources`, which is a list of dictionaries, each
> > one having an optional 'additional_flags' and a `srclist` pointing to
> > the list of custom_target generated sources.
> >
> > An example of a possible structure of bitcode_modules which is processed
> > by the main meson llvm bitcode emission file
> > src/backend/jit/llvm/bitcode/meson.build:
>
> I'm a bit doubtful this is worth doing, I don't think anything in there could
> be potentially inlineable...

Removed.

v13 is attached, it is much smaller compared to previous versions. I
liked that because I think it is easy to work on this feature now, we
can incrementally expand the feature later.


--
Regards,
Nazir Bilal Yavuz
Microsoft