From: Andre Muezerie <andremue@linux.microsoft.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH 2/2] devtools/dump-cpu-flags: add tool to update CPU flags table
Date: Fri, 28 Feb 2025 16:38:00 -0800 [thread overview]
Message-ID: <20250301003800.GA2378@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <Z8HJIBSXK8Um_YYa@bricha3-mobl1.ger.corp.intel.com>
On Fri, Feb 28, 2025 at 02:33:04PM +0000, Bruce Richardson wrote:
> On Thu, Feb 27, 2025 at 05:52:17PM -0800, Andre Muezerie wrote:
> > This patchset allows users to specify the CPU for which the generated
> > code should be optimized for by passing the CPU name.
> >
> > MSVC does not provide this functionality natively, so logic was
> > added. This additional logic relies on a table which stores instruction
> > set availability (like AXV512F) for different CPUs.
> > To make it easier to update this table a new devtool is introduced
> > with this patch. The new tool generates the table entries for all CPUs
> > listed in an input file using a recent version of the compiler, which
> > has all the information needed. This reduces enormously the amount
> > of work needed to update the table in msvc/meson.build and makes the
> > process much less error prone.
> >
> > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > ---
> > devtools/dump-cpu-flags/README.md | 25 +++++
> > devtools/dump-cpu-flags/cpu-names.txt | 120 +++++++++++++++++++++
> > devtools/dump-cpu-flags/dump-cpu-flags.cpp | 119 ++++++++++++++++++++
> > devtools/dump-cpu-flags/dump-cpu-flags.py | 41 +++++++
> > 4 files changed, 305 insertions(+)
> > create mode 100644 devtools/dump-cpu-flags/README.md
> > create mode 100644 devtools/dump-cpu-flags/cpu-names.txt
> > create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.cpp
> > create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.py
> >
> > diff --git a/devtools/dump-cpu-flags/README.md b/devtools/dump-cpu-flags/README.md
> > new file mode 100644
> > index 0000000000..3db69f9f8f
> > --- /dev/null
> > +++ b/devtools/dump-cpu-flags/README.md
> > @@ -0,0 +1,25 @@
> > +# Generating updated CPU flags
> > +
> > +File `config\x86\msvc\meson.build` has a table with flags indicating instruction set support for a variety of CPU types.
> > +
> > +Script `dump-cpu-flags.py` can be used to generate updated entries for this table.
> > +
> > +The CPU names are stored in file `cpu-names.txt`, which is consumed by `dump-cpu-flags.py`. The formatting used in that file is described at the top of the file itself.
> > +
> > +The script relies on the information embedded in the g++ compiler. This means that an updated table can automatically be generated by switching to a newer version of the compiler. This avoids the need to manually edit the entries, which is error prone. With the script the table entries can just copied and pasted into `meson.build`. The only thing that might need to be done is adding new CPU names to cpu-names.txt, when new CPUs are released.
> > +
> > +**NOTE**: CPUs not known to the compiler will result in errors, which can be ignored (`dump-cpu-flags.py` will ignore these errors and continue). For best results use the latest g++ compiler available.
> > +
> > +Below is a sample output, where an error was logged because the compiler did not know about a CPU named ‘raptorlake’.
> > +
> > +```sh
> > +$ ./dump-cpu-flags.py
> > + 'x86-64-v2': [],
> > + 'x86-64-v3': ['AVX', 'AVX2'],
> > + 'x86-64-v4': ['AVX', 'AVX2', 'AVX512F', 'AVX512VL', 'AVX512BW', 'AVX512DQ', 'AVX512CD'],
> > + 'alderlake': ['AVX', 'PCLMUL', 'RDRND', 'AVX2', 'RDSEED', 'AES', 'VPCLMULQDQ', 'GFNI'],
> > +cc1plus: error: bad value (‘raptorlake’) for ‘-march=’ switch
> > +cc1plus: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge...
> > + 'silvermont': ['PCLMUL', 'RDRND'],
> > + 'slm': ['PCLMUL', 'RDRND'],
> > +```
> > \ No newline at end of file
>
> How about having the tool output a valid meson.build file, that can then be
> used directly without copy-paste. While I know such a thing would end up
> with us having deep subdir structures, it could be just loaded from e.g.
> config/x86/msvc/cpu-flags/meson.build, for example.
>
> /Bruce
That's an interesting idea. It could be done, but when I think that this
table will probably get updated no more than once per release I don't see
much reason to to come up with something more sofisticated.
Sometimes it's better to keep things simple.
next prev parent reply other threads:[~2025-03-01 0:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 1:52 [PATCH 0/2] allow AVX512 instructions to be used with MSVC Andre Muezerie
2025-02-28 1:52 ` [PATCH 1/2] config: " Andre Muezerie
2025-02-28 14:30 ` Bruce Richardson
2025-03-01 0:47 ` Andre Muezerie
2025-02-28 1:52 ` [PATCH 2/2] devtools/dump-cpu-flags: add tool to update CPU flags table Andre Muezerie
2025-02-28 14:33 ` Bruce Richardson
2025-03-01 0:38 ` Andre Muezerie [this message]
2025-02-28 21:43 ` [PATCH v2 0/2] allow AVX512 instructions to be used with MSVC Andre Muezerie
2025-02-28 21:43 ` [PATCH v2 1/2] config: " Andre Muezerie
2025-02-28 21:43 ` [PATCH v2 2/2] devtools/dump-cpu-flags: add tool to update CPU flags table Andre Muezerie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250301003800.GA2378@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=andremue@linux.microsoft.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).