Re: add AVX2 support to simd.h - Mailing list pgsql-hackers

From John Naylor
Subject Re: add AVX2 support to simd.h
Date
Msg-id CANWCAZZX8Mi+q5oakCcGXOdrZ9GpdVTQ1cF8NUCnFirr+faTKQ@mail.gmail.com
Whole thread Raw
In response to Re: add AVX2 support to simd.h  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Oversight in reparameterize_path_by_child leading to executor crash
Next
From: ywgrit
Date:
Subject: Change comments of removing useless joins.