On 2023/08/12 8:30, Jeff Law 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. > > jeff >
I'll not be able to attend that meeting due to Japanese religious events around Aug 13-16 (it may not be impossible but at least difficult) but look forward seeing that some conclusion is made. I leave two patch sets corresponding two options so in either case, we can apply a fix after the conclusion is made. (1) __builtin_riscv_pause for 'Zihintpause'-only <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626912.html> (2) __builtin_riscv_pause for all <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626909.html> Thanks, Tsukasa
