Re: add AVX2 support to simd.h

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: add AVX2 support to simd.h
Date: 2024-01-08 09:03:50
Message-ID: CANWCAZZX8Mi+q5oakCcGXOdrZ9GpdVTQ1cF8NUCnFirr+faTKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 6, 2024 at 12:04 AM Nathan Bossart <nathandbossart(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ywgrit 2024-01-08 09:11:44 Change comments of removing useless joins.
Previous Message Richard Guo 2024-01-08 08:32:37 Re: Oversight in reparameterize_path_by_child leading to executor crash