Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2022-11-15 Thread Philipp Tomsich
On Tue, 15 Nov 2022 at 17:40, Jeff Law wrote: > > > On 11/13/22 13:41, Philipp Tomsich wrote: > > The Zihintpause extension uses an opcode from the 'fence' opcode range > > to add a true hint instruction (i.e. if it is not supported on any > > given platform, the 'fence' that is encoded will not

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2022-11-15 Thread Jeff Law via Gcc-patches
On 11/13/22 13:41, Philipp Tomsich wrote: The Zihintpause extension uses an opcode from the 'fence' opcode range to add a true hint instruction (i.e. if it is not supported on any given platform, the 'fence' that is encoded will not enforce any specific ordering on memory accesses) for

[PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2022-11-13 Thread Philipp Tomsich
The Zihintpause extension uses an opcode from the 'fence' opcode range to add a true hint instruction (i.e. if it is not supported on any given platform, the 'fence' that is encoded will not enforce any specific ordering on memory accesses) for entering a low-power state (e.g. in an idle thread).

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-02-18 Thread Jim Wilson
On Thu, Jan 7, 2021 at 12:50 AM Kito Cheng wrote: > My point is tracking info and consistent behavior/scheme with other > extensions, so personally I strongly prefer it should be guarded with > -march. > It is a hint. We should allow it even if the architecture extension is not enabled. For

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-07 Thread Kito Cheng via Gcc-patches
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

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-06 Thread Philipp Tomsich
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

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-06 Thread Kito Cheng
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

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-06 Thread Andrew Waterman via Gcc-patches
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

Re: [PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-06 Thread Kito Cheng via Gcc-patches
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:

[PATCH] RISC-V: Zihintpause: add __builtin_riscv_pause

2021-01-06 Thread Philipp Tomsich
The Zihintpause extension uses an opcode from the 'fence' opcode range to add a true hint instruction (i.e. if it is not supported on any given platform, the 'fence' that is encoded will not enforce any specific ordering on memory accesses) for entering a low-power state (e.g. in an idle thread).