public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: James Greenhalgh <james.greenhalgh@arm.com>
To: Tejas Belagod <tbelagod@arm.com>
Cc: Yufeng Zhang <yufengzhangdev@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Marc Glisse <marc.glisse@inria.fr>,
	Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Subject: Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.
Date: Fri, 04 Jul 2014 14:27:00 -0000	[thread overview]
Message-ID: <20140704142724.GA18513@arm.com> (raw)
In-Reply-To: <53AD8E83.8020201@arm.com>

On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
> +/* Internal scalar builtin types.  These types are used to support
> +   neon intrinsic builtins.  They are _not_ user-visible types.  Therefore
> +   the mangling for these types are implementation defined.  */
> +const char *aarch64_scalar_builtin_types[] = {
> +  "__builtin_aarch64_simd_qi",
> +  "__builtin_aarch64_simd_hi",
> +  "__builtin_aarch64_simd_si",
> +  "__builtin_aarch64_simd_sf",
> +  "__builtin_aarch64_simd_di",
> +  "__builtin_aarch64_simd_df",
> +  "__builtin_aarch64_simd_poly8",
> +  "__builtin_aarch64_simd_poly16",
> +  "__builtin_aarch64_simd_poly64",
> +  "__builtin_aarch64_simd_poly128",
> +  "__builtin_aarch64_simd_ti",
> +  "__builtin_aarch64_simd_uqi",
> +  "__builtin_aarch64_simd_uhi",
> +  "__builtin_aarch64_simd_usi",
> +  "__builtin_aarch64_simd_udi",
> +  "__builtin_aarch64_simd_ei",
> +  "__builtin_aarch64_simd_oi",
> +  "__builtin_aarch64_simd_ci",
> +  "__builtin_aarch64_simd_xi",
> +  NULL
> +};
<snip>
> +static const char *
> +aarch64_mangle_builtin_scalar_type (const_tree type)
> +{
> +  int i = 0;
> +
> +  while (aarch64_scalar_builtin_types[i] != NULL)
>      {
> -      default:
> -	eltype = aarch64_build_scalar_type (GET_MODE_INNER (mode),
> -					    unsigned_p, poly_p);
> -	return build_vector_type_for_mode (eltype, mode);
> -	break;
> -      VECTOR_TYPES
> -   }
> +      const char *name = aarch64_scalar_builtin_types[i];
> +
> +      if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
> +	  && DECL_NAME (TYPE_NAME (type))
> +	  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), name))
> +	return aarch64_scalar_builtin_types[i];
> +      i++;
> +    }
> +  return NULL;
>  }
<snip>
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 3ed8a98..50d294e 100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -32,66 +32,45 @@
> +typedef __Poly8_t poly8_t;
> +typedef __Poly16_t poly16_t;
> +typedef __Poly64_t poly64_t;
> +typedef __Poly128_t poly128_t;

This looks wrong to me. The type which eventually becomes poly8_t in
arm_neon.h has "__Poly8_t" as its internal type name.

When you go through the loop in aarch64_mangle_builtin_scalar_type you'll
be checking in aarch64_scalar_builtin_types for a string matching
"__Poly8_t" and won't find it, so we'll end up with default mangling for this
type.

One question I have is, if for all the backend types we define we want the
mangled name to be:

  <strlen (type)><type>

then why do we not just return that and save the string comparisons?

I can see some argument for future flexibility, but in that case we will need
to rewrite this code anyway. Is there some other hole in my reasoning?

Thanks,
James


  parent reply	other threads:[~2014-07-04 14:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 15:48 Tejas Belagod
2014-06-25  8:31 ` Yufeng Zhang
2014-06-27 15:32   ` Tejas Belagod
2014-06-27 16:01     ` Yufeng Zhang
2014-08-22 12:02       ` Tejas Belagod
2014-07-04 14:27     ` James Greenhalgh [this message]
2014-08-22 12:07       ` Tejas Belagod
2014-07-08 16:00     ` James Greenhalgh
2014-06-28 10:25 ` Marc Glisse
2014-08-22 11:59   ` Tejas Belagod
2014-08-22 12:54     ` Marc Glisse

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=20140704142724.GA18513@arm.com \
    --to=james.greenhalgh@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=marc.glisse@inria.fr \
    --cc=tbelagod@arm.com \
    --cc=yufengzhangdev@gmail.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).