On Sun, Aug 13, 2023 at 12:53 PM Philipp Tomsich <philipp.toms...@vrull.eu> 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.
I continue to think that, since it's semantically valid to execute a HINT on any implementation, there's little utility in ever rejecting the HINT builtins, or in rejecting explicit HINTs in asm, irrespective of -march. But ultimately it isn't a big deal either way. > 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.
