On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart <nathandboss...@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.
