public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Philipp Tomsich <philipp.tomsich@vrull.eu>
To: Kito Cheng <kito.cheng@sifive.com>
Cc: Andrew Waterman <aswaterman@gmail.com>,
	Kito Cheng <kito.cheng@gmail.com>,  Jim Wilson <jimw@sifive.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause
Date: Thu, 7 Jan 2021 07:53:30 +0100	[thread overview]
Message-ID: <CAAeLtUDzSh=jnSvAPmz1Zt3HykpYKWM74vX9+pdpYA58WiLTog@mail.gmail.com> (raw)
In-Reply-To: <CALLt3TjR3k9hR2ocTw33QALWPRYGHn8Lqt0dufBeSujaAhttKw@mail.gmail.com>

Kito:

We had originally considered to guard this with a -march, but decided
against it
eventually: this instruction will be (among other cases) used in the
cpu_relax() of
the Linux kernel.  For cases like that, we should consider this the
baseline (i.e.
either there's no pause—in which case, the encoded fence will not hurt—or
the
Zihintpause extension)... but it all maps back to a single builtin-call.

Note that the Zihintfence will be enabled for all (also older) targets, as
the insn
is supported there as well (as a fence that doesn't do anything)... so
guarding it
will not really change the behavior.

That said, I'll get going on an v2 that will include the -march guard (and
we can
still turn things back to how they are today).

Thanks,
Philipp.

On Thu, 7 Jan 2021 at 06:42, Kito Cheng <kito.cheng@sifive.com> wrote:

> Hi Andrew:
>
> It's safe to execute on old machine, but it is still a new extension not
> included on baseline ISA, so I still prefer having -march to guard that,
> and then we can track that in the ELF attribute to see what extensions and
> which version are used in the executable / object files.
>
>
> On Thu, Jan 7, 2021 at 11:51 AM Andrew Waterman <aswaterman@gmail.com>
> wrote:
>
>> I've got a contrary opinion:
>>
>> Since HINTs are guaranteed to execute as no-ops--e.g., this one is
>> just a FENCE instruction, which is already a mandatory part of the
>> base ISA--they don't _need_ to be called out as separate extensions in
>> the toolchain.
>>
>> Although there's nothing fundamentally wrong with Kito's suggestion,
>> it seems like an extra hoop to jump through without commensurate
>> benefit.  I see no reason to restrict the use of __builtin_pause,
>> since all RISC-V implementations, including old ones, are required to
>> support it.  And, of course, that's the reason we encoded it this way
>> :)
>>
>>
>> On Wed, Jan 6, 2021 at 7:35 PM Kito Cheng <kito.cheng@gmail.com> wrote:
>> >
>> > Hi Philipp:
>> >
>> > Could you add zihintpause to -march parser and guard that on the
>> > pattern and builtin like zifencei[1-2]?
>> >
>> > And could you sent a PR to
>> > https://github.com/riscv/riscv-c-api-doc/blob/master/riscv-c-api.md to
>> > mention __builtin_riscv_pause?
>> >
>> > Thanks!
>> >
>> > [1] march parser change:
>> >
>> https://github.com/gcc-mirror/gcc/commit/b03be74bad08c382da47e048007a78fa3fb4ef49
>> > [2] Default version for ext.:
>> >
>> https://github.com/gcc-mirror/gcc/commit/4b81528241ca682025d92558ff6aeec91dafdca8
>> >
>> >
>> > > --- /dev/null
>> > > +++ b/gcc/testsuite/gcc.target/riscv/builtin_pause.c
>> > > @@ -0,0 +1,10 @@
>> > > +/* { dg-do compile } */
>> > > +/* { dg-options "-O2" }  */
>> > > +
>> > > +void test_pause()
>> >
>> > I would suggest you change the function name in the testcase,
>> > otherwise the scan-assembler test will always pass even if you didn't
>> > generate "pause" instruction.
>> >
>> >
>> > > +{
>> > > +  __builtin_riscv_pause ();
>> > > +}
>> > > +
>> > > +/* { dg-final { scan-assembler "pause" } } */
>> > > +
>> > > --
>> > > 2.18.4
>> > >
>>
>

  reply	other threads:[~2021-01-07  6:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 17:33 Philipp Tomsich
2021-01-07  3:35 ` Kito Cheng
2021-01-07  3:50   ` Andrew Waterman
2021-01-07  5:41     ` Kito Cheng
2021-01-07  6:53       ` Philipp Tomsich [this message]
2021-01-07  8:49         ` Kito Cheng
2021-02-18 20:21           ` Jim Wilson
2022-11-13 20:41 Philipp Tomsich
2022-11-15 16:40 ` Jeff Law
2022-11-15 22:12   ` Philipp Tomsich

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='CAAeLtUDzSh=jnSvAPmz1Zt3HykpYKWM74vX9+pdpYA58WiLTog@mail.gmail.com' \
    --to=philipp.tomsich@vrull.eu \
    --cc=aswaterman@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jimw@sifive.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.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).