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 e
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 entering
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).
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 co
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
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 e
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 Thu,
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 wit
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:
https://github.c
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).
10 matches
Mail list logo