public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@cavium.com>
To: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>,
	gcc-patches	 <gcc-patches@gcc.gnu.org>
Cc: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
	Richard Sandiford <Richard.Sandiford@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	 James Greenhalgh <James.Greenhalgh@arm.com>,
	Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Subject: Re: [Patch][Aarch64] Implement Aarch64 SIMD ABI and aarch64_vector_pcs attribute
Date: Tue, 07 Aug 2018 16:01:00 -0000	[thread overview]
Message-ID: <1533657677.3879.99.camel@cavium.com> (raw)
In-Reply-To: <1533593632.3879.90.camel@cavium.com>

I have a question about my own patch.  In doing testing I realized
that if I use the aarch64_vector_pcs attribute on a platform without
SIMD (i.e. -march=armv8.1-a+nosimd) I get an ICE.  That is obviously
not what we want but I was wondering what the right behaviour is.

We certainly don't want to generate code for a SIMD function on a
target that does not support SIMD, but is it OK to declare something
with the simd or aarch64_vector_pcs attribute if it is never used or called?
Or should even the declaration of a function with the simd/aarch64_vector_pcs
attribute result in a compilation error?  I don't think we want to
complain about simd declarations because those could show up in the system
headers like mathcalls.h even when not used.  Or should those be ifdef'ed
in some way based on the __ARM_NEON macro so they don't show up when not
compiling for SIMD?

Any ideas on where should this check be done, I thought the
TARGET_OPTION_VALID_ATTRIBUTE_P hook might be the right place, but that
seems to be specific to the 'target' attribute only, not attributes
in general.

Steve Ellcey
sellcey@cavium.com

  reply	other threads:[~2018-08-07 16:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 22:25 Steve Ellcey
2018-08-01 12:14 ` Kyrill Tkachov
2018-08-06 22:14   ` Steve Ellcey
2018-08-07 16:01     ` Steve Ellcey [this message]
2018-08-07 17:37     ` Segher Boessenkool
2018-08-20 17:37       ` Steve Ellcey
2018-08-31 17:54         ` Steve Ellcey
2018-09-04 11:38         ` Kyrill Tkachov
     [not found]           ` <DB5PR08MB1030070F731C5909C6FFEC0283030@DB5PR08MB1030.eurprd08.prod.outlook.com>
2018-09-04 17:20             ` Wilco Dijkstra
2018-09-04 20:50               ` Steve Ellcey

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=1533657677.3879.99.camel@cavium.com \
    --to=sellcey@cavium.com \
    --cc=James.Greenhalgh@arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@foss.arm.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).