From: Uros Bizjak <ubizjak@gmail.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek <jakub@redhat.com>,
Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)
Date: Fri, 2 Dec 2022 10:54:51 +0100 [thread overview]
Message-ID: <CAFULd4bvdHXCVB-jToxF=gb+-hf1B_=rDZ7UOhgePTf5B8oPBQ@mail.gmail.com> (raw)
In-Reply-To: <57fb7194-0c9a-2b7c-d671-521b9b4d2b71@suse.cz>
On Fri, Dec 2, 2022 at 10:46 AM Martin Liška <mliska@suse.cz> wrote:
>
> PING^1
>
> On 11/25/22 13:57, Martin Liška wrote:
> > Similar story as PR103661, we again return a negative number
> > for __builtin_cpu_supports:
> >
> > Documentation says:
> >
> > int __builtin_cpu_supports(const char *feature)
> > This function returns a positive integer if the run-time CPU supports feature and returns 0 otherwise.
> > while we return -2147483648.
> >
> > Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
> > but for __builtin_cpu_supports.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > PR target/107551
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
> > as for PR103661.
> > * doc/extend.texi: Fix "x86-64" use.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/builtin_target.c: Add more checks.
I'm not quite familiar with this part of the compiler, but if Jakub is
OK with the patch, consider it rubber-stamped OK.
Thanks,
Uros.
> > ---
> > gcc/config/i386/i386-builtins.cc | 25 ++++++++-----------
> > gcc/doc/extend.texi | 22 ++++++++--------
> > .../gcc.target/i386/builtin_target.c | 5 ++++
> > 3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/gcc/config/i386/i386-builtins.cc b/gcc/config/i386/i386-builtins.cc
> > index eacdf072244..c57c1380298 100644
> > --- a/gcc/config/i386/i386-builtins.cc
> > +++ b/gcc/config/i386/i386-builtins.cc
> > @@ -2181,18 +2181,14 @@ fold_builtin_cpu (tree fndecl, tree *args)
> > varpool_node::add (ix86_cpu_features2_var);
> > }
> >
> > + /* Skip __cpu_features[0]. */
> > feature -= INT_TYPE_SIZE;
> > - field_val = 1U << (feature % INT_TYPE_SIZE);
> > tree index = size_int (feature / INT_TYPE_SIZE);
> > + feature = feature % INT_TYPE_SIZE;
> > array_elt = build4 (ARRAY_REF, unsigned_type_node,
> > ix86_cpu_features2_var,
> > index, NULL_TREE, NULL_TREE);
> > /* Return __cpu_features2[index] & field_val */
> > - final = build2 (BIT_AND_EXPR, unsigned_type_node,
> > - array_elt,
> > - build_int_cstu (unsigned_type_node,
> > - field_val));
> > - return build1 (NOP_EXPR, integer_type_node, final);
> > }
> > else
> > {
> > @@ -2209,16 +2205,17 @@ fold_builtin_cpu (tree fndecl, tree *args)
> > array_elt = build4 (ARRAY_REF, unsigned_type_node, ref,
> > integer_zero_node, NULL_TREE, NULL_TREE);
> >
> > - field_val = (1U << feature);
> > /* Return __cpu_model.__cpu_features[0] & field_val */
> > - final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> > - build_int_cstu (unsigned_type_node, field_val));
> > - if (feature == (INT_TYPE_SIZE - 1))
> > - return build2 (NE_EXPR, integer_type_node, final,
> > - build_int_cst (unsigned_type_node, 0));
> > - else
> > - return build1 (NOP_EXPR, integer_type_node, final);
> > }
> > +
> > + field_val = (1U << feature);
> > + final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> > + build_int_cstu (unsigned_type_node, field_val));
> > + if (feature == (INT_TYPE_SIZE - 1))
> > + return build2 (NE_EXPR, integer_type_node, final,
> > + build_int_cst (unsigned_type_node, 0));
> > + else
> > + return build1 (NOP_EXPR, integer_type_node, final);
> > }
> > gcc_unreachable ();
> > }
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index b1dd39e64b8..d3812fa55b0 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -21897,18 +21897,6 @@ AMD Family 19h Zen version 3.
> >
> > @item znver4
> > AMD Family 19h Zen version 4.
> > -
> > -@item x86-64
> > -Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> > -
> > -@item x86-64-v2
> > -x86-64-v2 microarchitecture level.
> > -
> > -@item x86-64-v3
> > -x86-64-v3 microarchitecture level.
> > -
> > -@item x86-64-v4
> > -x86-64-v4 microarchitecture level.
> > @end table
> >
> > Here is an example:
> > @@ -22002,6 +21990,16 @@ VPCLMULQDQ instructions.
> > AVX512VNNI instructions.
> > @item avx512bitalg
> > AVX512BITALG instructions.
> > +@item x86-64
> > +Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> > +@item x86-64-v2
> > +x86-64-v2 microarchitecture level.
> > +@item x86-64-v3
> > +x86-64-v3 microarchitecture level.
> > +@item x86-64-v4
> > +x86-64-v4 microarchitecture level.
> > +
> > +
> > @end table
> >
> > Here is an example:
> > diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c b/gcc/testsuite/gcc.target/i386/builtin_target.c
> > index 3e7505a8c3a..fff643c13b0 100644
> > --- a/gcc/testsuite/gcc.target/i386/builtin_target.c
> > +++ b/gcc/testsuite/gcc.target/i386/builtin_target.c
> > @@ -95,6 +95,11 @@ quick_check ()
> >
> > assert (__builtin_cpu_supports ("avx512vpopcntdq") >= 0);
> >
> > + assert (__builtin_cpu_supports ("x86-64") >= 0);
> > + assert (__builtin_cpu_supports ("x86-64-v2") >= 0);
> > + assert (__builtin_cpu_supports ("x86-64-v3") >= 0);
> > + assert (__builtin_cpu_supports ("x86-64-v4") >= 0);
> > +
> > /* Check CPU type. */
> > assert (__builtin_cpu_is ("amd") >= 0);
> >
>
next prev parent reply other threads:[~2022-12-02 9:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 12:57 Martin Liška
2022-12-02 9:46 ` Martin Liška
2022-12-02 9:54 ` Uros Bizjak [this message]
2022-12-07 10:30 ` Martin Liška
2022-12-07 11:27 ` Jakub Jelinek
2022-12-09 9:18 ` Martin Liška
2022-12-09 9:31 ` Jakub Jelinek
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='CAFULd4bvdHXCVB-jToxF=gb+-hf1B_=rDZ7UOhgePTf5B8oPBQ@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
--cc=mliska@suse.cz \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).