Date: Fri, 5 Jan 2024 11:04:27 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Ants Aasma <ants@cybertec.at>, pgsql-hackers@postgresql.org
Subject: Re: add AVX2 support to simd.h
Message-ID: <20240105170427.GD2168314@nathanxps13>
References: <20231129171526.GA857928@nathanxps13>
 <CANWCAZZHEHufYD7nPNX6sPZ1mHo+30qTiV5UPXL_evh-N=1n5g@mail.gmail.com>
 <20240102161123.GA955987@nathanxps13>
 <CANWCAZavit+92_2E4K04RD7ErzY2T1Cc=3tysLYLk17t_GnM-g@mail.gmail.com>
 <20240103152954.GA1300001@nathanxps13>
 <CANWCAZa5Um69a4FWbemQniTckNfkAW708pMLkx0NajvHZagtYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANWCAZa5Um69a4FWbemQniTckNfkAW708pMLkx0NajvHZagtYQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20240105170427.GD2168314%40nathanxps13>
Precedence: bulk

On Fri, Jan 05, 2024 at 09:03:39AM +0700, John Naylor wrote:
> On Wed, Jan 3, 2024 at 10:29 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> If the requirement is that normal builds use AVX2, then I fear we will be
>> waiting a long time.  IIUC the current proposals (building multiple
>> binaries or adding a configuration option that maps to compiler flags)
>> would still be opt-in,
> 
> If and when we get one of those, I would consider that  a "normal"
> build. Since there are no concrete proposals yet, I'm still waiting
> for you to justify imposing an immediate maintenance cost for zero
> benefit.

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.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com