public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Brown <julian@codesourcery.com>
To: Marcel Vollweiler <marcel@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] gcc/configure.ac: fix register issue for global_load assembler functions
Date: Wed, 16 Jun 2021 17:01:35 +0100	[thread overview]
Message-ID: <20210616170135.277c6859@squid.athome> (raw)
In-Reply-To: <d159201c-3edb-8078-4870-a13b1ff1cc22@codesourcery.com>

At the risk of overstepping my GCN backend review remit...

On Wed, 16 Jun 2021 11:34:53 +0200
Marcel Vollweiler <marcel@codesourcery.com> wrote:

> index d9fc3c2..e179ce1 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -5357,6 +5357,30 @@ case "$target" in
>      ;;
>  esac
>  
> +# This tests if the assembler supports two registers for global_load
> functions +# (like in LLVM versions <12) or one register (like in
> LLVM 12). +case "$target" in
> +  amdgcn-* | gcn-*)
> +    AC_MSG_CHECKING(assembler fix for global_load functions)
> +    gcc_cv_as_gcn_global_load_fixed=yes
> +    if test x$gcc_cv_as != x; then
> +      cat > conftest.s <<EOF
> +	global_store_dwordx2    v[[1:2]], v[[4:5]], s[[14:15]]
> +EOF
> +      if $gcc_cv_as -triple=amdgcn--amdhsa -filetype=obj
> -mcpu=gfx900 -o conftest.o conftest.s > /dev/null 2>&1; then
> +        gcc_cv_as_gcn_global_load_fixed=no
> +      fi
> +      rm -f conftest.s conftest.o conftest
> +    fi
> +    if test x$gcc_cv_as_gcn_global_load_fixed = xyes; then
> +      AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 1, [Define if your
> assembler has fixed global_load functions.])
> +    else
> +      AC_DEFINE(HAVE_GCN_ASM_GLOBAL_LOAD_FIXED, 0, [Define if your
> assembler has fixed global_load functions.])
> +    fi
> +    AC_MSG_RESULT($gcc_cv_as_gcn_global_load_fixed)
> +    ;;
> +esac

I think the more-common idiom seems to be just having a single
AC_DEFINE if the feature is present -- like (as a random example)
HAVE_AS_IX86_REP_LOCK_PREFIX, which omits the "define ... 0" case you
have here. (You'd use "#ifdef ..." instead of "#if ... == 1" to check
the feature then, of course).

Then OK with that change (as long as a global maintainer doesn't object
in, say, the next 24 hours?) -- but please watch the mailing list for
configuration problems that might spring up on other targets.

Thanks,

Julian

  reply	other threads:[~2021-06-16 16:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 14:47 Marcel Vollweiler
2021-06-14 12:36 ` Julian Brown
2021-06-14 13:28   ` Tobias Burnus
2021-06-14 14:26   ` Andrew Stubbs
2021-06-14 15:28   ` Julian Brown
2021-06-16  9:34 ` Marcel Vollweiler
2021-06-16 16:01   ` Julian Brown [this message]
2021-06-16 17:19     ` Joseph Myers
2021-06-17 13:50       ` Marcel Vollweiler
2021-06-17 20:31         ` Joseph Myers

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=20210616170135.277c6859@squid.athome \
    --to=julian@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=marcel@codesourcery.com \
    /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).