On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> I've been thinking about the configuration option approach. ISTM that
> would be the most feasible strategy, at least for v17. A couple things
> come to mind:
>
> * This option would simply map to existing compiler flags. We already have
> ways to provide those (-Dc_args in meson, CFLAGS in autoconf). Perhaps
> we'd want to provide our own shorthand for certain platforms (e.g., ARM),
> but that will still just be shorthand for compiler flags.
>
> * Such an option would itself generate some maintenance cost. That could
> be worth it because it formalizes the Postgres support for those options,
> but it's still one more thing to track.
>
> Another related option could be to simply document that we have support for
> some newer instructions that can be enabled by setting the aforementioned
> compiler flags. That's perhaps a little less user-friendly, but it'd avoid
> the duplication and possibly reduce the maintenance cost. I also wonder if
> it'd help prevent confusion when CFLAGS and this extra option conflict.
The last one might offer more graceful forward compatibility if the
multiple-binaries idea gets any traction some day, because at that
point the additional config options are not needed, I think.
Another consideration is which way would touch the fewest places to
work with Windows, which uses the spelling /arch:AVX2 etc.
One small thing I would hope for from the finial version of this is
the ability to inline things where we currently indirect depending on
a run-time check. That seems like "just work" on top of everything
else, and I don't think it makes a case for either of the above.
