On 8/13/23 13:52, Philipp Tomsich wrote:
On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On 8/9/23 16:39, Tsukasa OI wrote:
On 2023/08/10 5:05, Jeff Law wrote:
I'd tend to think we do not want to expose the intrinsic unless the
right extensions are enabled -- even though the encoding is a no-op and
we could emit it as a .insn.
I think that makes sense. The only reason I implemented the
no-'Zihintpause' version is because GCC 13 implemented the built-in
unconditionally. If the compatibility breakage is considered minimum (I
don't know, though), I'm ready to submit 'Zihintpause'-only version of
this patch set.
While it's a compatibility break I don't think we have a need to
preserve this kind of compatibility. I suspect anyone using
__builtin_riscv_pause was probably already turning on Zihintpause and if
they weren't they should have been :-0
I'm sure we'll kick this around in the Tuesday meeting and hopefully
make a decision about the desired direction. You're obviously welcome
to join if you're inclined. Let me know if you need an invite.
The original discussion (and I believe that Andrew was the decisive
voice in the end) came to the conclusion that—given that pause is a
true hint—it could always be enabled.
We had originally expected to enable it only if Zihintpause was part
of the target architecture, but viewing it as "just a name for an
already existing pure hint" also made sense.
Note that on systems that don't implement Zihintpause, the hint is
guarantueed to not have an architectural effect.
That said, I don't really have a strong leaning one way or another.
Philipp.
I don't have a strong opinion either way and I certainly see both sides
of the argument.
It sounds like the current situation is by design; knowing that now I
would tend to lean towards keeping status quo, which would mean going
with Tsukasa's first patch or something similar.
We'll certainly discuss on the call in a half-hour or so.
jeff
