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.
