Feedback-ID: id4a34324:Fastmail
Date: Mon, 6 Apr 2026 16:09:26 -0400
From: Andres Freund <andres@anarazel.de>
To: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
	Peter Eisentraut <peter@eisentraut.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: meson vs. llvm bitcode files
Message-ID: <blfq7kk5bylebetudvyslef5j2bvigrqikmwy66i4znvkv63uy@smypdulfe7gb>
References: 
 <CAN55FZ3CN09j5o3PDw8wkiEqc4tt=7+VFwYriY451y=-9SN33A@mail.gmail.com>
 <CAN55FZ2vp2wuzMZVxzFqj=6wbSSs_REYFLbPJK9CaY2SHJTY=A@mail.gmail.com>
 <CAN55FZ138OBEehyxD1FKySMxKFteqf_VOR8LBkz-055YGU12rg@mail.gmail.com>
 <CAN55FZ3HTYjtooYWtGGhDQnSJWqPJmC+wszLGvnK36LwgC2uQA@mail.gmail.com>
 <4286824f-40c3-4716-ad71-2085b83f3736@eisentraut.org>
 <CAN55FZ0KxMphg+M+4Shm=HmNV+XhC7LUKc6hrC+-QiovhzvdVA@mail.gmail.com>
 <CAN4CZFNLJ9_-0H7kCQA+CLnjvS3eU=oq2=TPjCqbP+VhOg9CsQ@mail.gmail.com>
 <CAN55FZ1FmSdbs5A8rYLjcHT=91=mfviv58-K66y5h2RTB_4hjw@mail.gmail.com>
 <CAN4CZFO0XdH+9BZRLC4P=+zCZ3WUvkwGMc0jEV92CfPaU0ePpw@mail.gmail.com>
 <CAN55FZ1=Tby+wibH1TkWMaKu_Xkj9aw9-XAToZBov0ovqzmHKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAN55FZ1=Tby+wibH1TkWMaKu_Xkj9aw9-XAToZBov0ovqzmHKg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/blfq7kk5bylebetudvyslef5j2bvigrqikmwy66i4znvkv63uy%40smypdulfe7gb>
Precedence: bulk

Hi,

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?

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


> 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.


> +  # 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.


> 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
> ---
>  contrib/bloom/meson.build             |  5 +++++
>  contrib/bool_plperl/meson.build       |  9 +++++++++
>  contrib/btree_gin/meson.build         |  5 +++++
>  contrib/btree_gist/meson.build        |  5 +++++
>  contrib/citext/meson.build            |  5 +++++
>  contrib/cube/meson.build              | 18 ++++++++++++++++++
>  contrib/dict_int/meson.build          |  5 +++++
>  contrib/dict_xsyn/meson.build         |  5 +++++
>  contrib/earthdistance/meson.build     |  6 ++++++
>  contrib/fuzzystrmatch/meson.build     |  9 +++++++++
>  contrib/hstore/meson.build            |  7 +++++++
>  contrib/hstore_plperl/meson.build     | 10 ++++++++++
>  contrib/hstore_plpython/meson.build   | 11 +++++++++++
>  contrib/intarray/meson.build          |  5 +++++
>  contrib/isn/meson.build               |  5 +++++
>  contrib/jsonb_plperl/meson.build      |  8 ++++++++
>  contrib/jsonb_plpython/meson.build    | 10 ++++++++++
>  contrib/lo/meson.build                |  5 +++++
>  contrib/ltree/meson.build             | 10 ++++++++++
>  contrib/ltree_plpython/meson.build    | 11 +++++++++++
>  contrib/pg_buffercache/meson.build    |  5 +++++
>  contrib/pg_freespacemap/meson.build   |  5 +++++
>  contrib/pg_logicalinspect/meson.build |  5 +++++
>  contrib/pg_surgery/meson.build        |  4 ++++
>  contrib/pg_trgm/meson.build           |  5 +++++
>  contrib/pgcrypto/meson.build          |  4 ++++
>  contrib/seg/meson.build               | 12 ++++++++++++
>  contrib/spi/meson.build               | 20 ++++++++++++++++++++
>  contrib/sslinfo/meson.build           |  5 +++++
>  contrib/tablefunc/meson.build         |  5 +++++
>  contrib/tcn/meson.build               |  5 +++++
>  contrib/tsm_system_rows/meson.build   |  5 +++++
>  contrib/tsm_system_time/meson.build   |  5 +++++
>  contrib/unaccent/meson.build          |  5 +++++
>  contrib/uuid-ossp/meson.build         |  5 +++++
>  contrib/xml2/meson.build              |  5 +++++
>  meson.build                           |  1 +
>  src/interfaces/libpq/meson.build      |  3 +++
>  src/pl/plperl/meson.build             |  1 +
>  src/pl/plpython/meson.build           |  1 +
>  40 files changed, 260 insertions(+)

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.


> 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...


Greetings,

Andres Freund