public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Peter Bergner <bergner@linux.ibm.com>,
	gcc@gcc.gnu.org, libc-alpha@sourceware.org,
	linuxppc-dev@lists.ozlabs.org,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul E Murphy <murphyp@linux.ibm.com>
Subject: Re: [PATCH Linux] powerpc: add documentation for HWCAPs
Date: Fri, 15 Jul 2022 11:00:48 +1000	[thread overview]
Message-ID: <1657845835.tt8ymcybhd.astroid@bobo.none> (raw)
In-Reply-To: <20220524173814.GH25951@gate.crashing.org>

Finally got some details about the icache snoop question so just coming 
back to this now, sorry for the delay... (POWER10 does support the 
coherent icache flush sequence as expected, there was some updates to
the UM wording but that will be fixed).

Excerpts from Segher Boessenkool's message of May 25, 2022 3:38 am:
> Hi!
> 
> On Tue, May 24, 2022 at 07:38:28PM +1000, Nicholas Piggin wrote:
>> Thanks for all the comments and corrections. It should be nearing the
>> point where it is useful now. Yes I do think it would be useful to align
>> this more with OpenPOWER docs (and possibly eventually move it into the
>> ABI, given that's the allocator of these numbers) but that's not
>> done yet.
> 
> The auxiliary vector is a Linux/glibc thing, it should not be described
> in more generic ABI documents.  It is fine where you have it now afaics.

It is already in the ABI document. In fact that (not the kernel) had
been the allocator of the feature numbers, at least in the past I think.

> 
>> +Where software relies on a feature described by a HWCAP, it should check the
>> +relevant HWCAP flag to verify that the feature is present before attempting to
>> +make use of the feature.
>> +
>> +Features should not be probed through other means. When a feature is not
>> +available, attempting to use it may result in unpredictable behaviour, and
>> +may not be guaranteed to result in any reliable indication that the feature
>> +is unavailable.
> 

> Traditionally VMX was tested for by simply executing an instruction and
> catching SIGILL.  This is portable even.  This has worked fine for over
> two decades, it's a bit weird to declare this a forbidden practice
> now :-)

The statement does not override architectural specification, so
if an encoding does not exist then it should cause a trap and SIGILL.
I suppose in theory we could work around performance or correctness
issues in an implementation by clearing HWCAP even if the hardware does 
execute the instruction, so I would still say testing HWCAP is
preferred.

> 
> It certainly isn't recommended for more complex and/or newer things.
> 
>> +verstions.
> 
> (typo.  spellcheck maybe?)

Thanks,
Nick

  reply	other threads:[~2022-07-15  1:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  9:38 Nicholas Piggin
2022-05-24  9:52 ` Florian Weimer
2022-05-24 18:32   ` Segher Boessenkool
2022-07-15  1:17     ` Nicholas Piggin
2022-07-15 14:35       ` Segher Boessenkool
2022-05-24 17:38 ` Segher Boessenkool
2022-07-15  1:00   ` Nicholas Piggin [this message]
2023-06-06 14:49 ` Passing the complex args in the GPR's Umesh Kalappa
2023-06-06 14:58   ` Andrew Pinski
2023-06-06 15:05     ` Umesh Kalappa
2023-06-06 15:16       ` Andrew Pinski
2023-06-06 16:42       ` Segher Boessenkool
2023-06-06 17:07         ` Umesh Kalappa
2023-06-06 17:33           ` David Edelsohn
2023-06-07 13:17           ` Michael Matz
2023-06-06 17:18     ` 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=1657845835.tt8ymcybhd.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=bergner@linux.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=murphyp@linux.ibm.com \
    --cc=segher@kernel.crashing.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 read-only IMAP folder(s) and NNTP newsgroup(s).