public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@gmail.com>
To: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Kito Cheng <kito.cheng@sifive.com>,
	Andrew Waterman <aswaterman@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 16:49:51 +0800	[thread overview]
Message-ID: <CA+yXCZDFve5xgaVPZJzv9P6+8YPwbx=nwtT2gWvH31KoC-8OjA@mail.gmail.com> (raw)
In-Reply-To: <CAAeLtUDzSh=jnSvAPmz1Zt3HykpYKWM74vX9+pdpYA58WiLTog@mail.gmail.com>

My point is tracking info and consistent behavior/scheme with other
extensions, so personally I strongly prefer it should be guarded with
-march.

But maybe we could create an issue on riscv-c-api-doc[1] or
riscv-toolchain-conventions[2] to
get feedback from LLVM folks, since I think this behavior should align
between LLVM and GCC.

[1] https://github.com/riscv/riscv-c-api-doc
[2] https://github.com/riscv/riscv-toolchain-conventions

On Thu, Jan 7, 2021 at 2:53 PM Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
>
> 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  8:50 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
2021-01-07  8:49         ` Kito Cheng [this message]
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='CA+yXCZDFve5xgaVPZJzv9P6+8YPwbx=nwtT2gWvH31KoC-8OjA@mail.gmail.com' \
    --to=kito.cheng@gmail.com \
    --cc=aswaterman@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jimw@sifive.com \
    --cc=kito.cheng@sifive.com \
    --cc=philipp.tomsich@vrull.eu \
    /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).