nemanjai wrote:
> > Should we use strings like ARM does so we can get register by name?
>
> Good point! We may provide two kinds of builtins: one by name, and another by
> CSR number. We should continue @lenary's proposal and discuss it in
> https://github.com/riscv-non-isa/riscv-toolchain-con
wangpc-pp wrote:
> Should we use strings like ARM does so we can get register by name?
Good point! We may provide two kinds of builtins: one by name, and another by
CSR number.
We should continue @lenary's proposal and discuss it in
https://github.com/riscv-non-isa/riscv-toolchain-conventions
topperc wrote:
Should we use strings like ARM does so we can get register by name?
https://github.com/llvm/llvm-project/pull/85091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
wangpc-pp wrote:
GCC gained its `__arm_rsr` and `__arm_wsr` support last year (October, 2023):
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631855.html. So there is
no stable released GCC version that supports these builtins.
Clang supported these builtins about nine years ago:
https
jrtc27 wrote:
I guess my underlying point is that Arm's ACLE provides functions like
__arm_rsr, but I'm not aware of them really being used, with inline assembly
being the far more common alternative, so what's the real point of providing an
interface that developers have already demonstrated
nemanjai wrote:
> You can just use `({ ... })` to achieve that same goal with inline assembly
> (and write doesn't even need that, you can do it with a single statement).
> I'm not convinced the intrinsics gain you anything.
Hmm... I think there's a bit of a disconnect here between the point I
jrtc27 wrote:
You can just use `({ ... })` to achieve that same goal with inline assembly
(and write doesn't even need that, you can do it with a single statement). I'm
not convinced the intrinsics gain you anything.
https://github.com/llvm/llvm-project/pull/85091
_
asb wrote:
> In my view, the builtin solution is superior from a usability perspective.
I agree, I think Sam's previous work on this stopped due to changing priorities
not because there was any real pushback.
https://github.com/llvm/llvm-project/pull/85091
_
nemanjai wrote:
> > > I have always been unconvinced that these are a good idea to have / add
> > > significant value over using inline assembly. IIRC Arm has them but
> > > nobody uses them?
...
> If it’s not a constant integer for inline assembly then how would it
> magically be a constant
wangpc-pp wrote:
> > > I support adding these builtins personally, but I think we need more
> > > discussions on the design. We can achieve the same thing via inline
> > > assemblies, that's true. But, from the compiler side, inline assemblies
> > > are kind of barriers, we can't do a lot of o
jrtc27 wrote:
> > I support adding these builtins personally, but I think we need more
> > discussions on the design. We can achieve the same thing via inline
> > assemblies, that's true. But, from the compiler side, inline assemblies are
> > kind of barriers, we can't do a lot of optimization
topperc wrote:
> I support adding these builtins personally, but I think we need more
> discussions on the design. We can achieve the same thing via inline
> assemblies, that's true. But, from the compiler side, inline assemblies are
> kind of barriers, we can't do a lot of optimizations/reord
wangpc-pp wrote:
I support adding these builtins personally, but I think we need more
discussions on the design.
We can achieve the same thing via inline assemblies, that's true. But, from the
compiler side, inline assemblies are kind of barriers, we can't do a lot of
optimizations/reorderings
jrtc27 wrote:
> > I have always been unconvinced that these are a good idea to have / add
> > significant value over using inline assembly. IIRC Arm has them but nobody
> > uses them?
>
> Is this a comment about the general concept of builtins to produce specific
> instructions or about these
@@ -74,6 +74,21 @@ let TargetPrefix = "riscv" in {
} // TargetPrefix = "riscv"
+let TargetPrefix = "riscv" in {
+ // Zicsr
+ def int_riscv_csrr :
+DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty],
+ [IntrNoMem, IntrHasSideEffects,
ImmArg>]>;
@@ -20,6 +20,12 @@ class RISCVBuiltin :
TargetBuiltin {
let Attributes = [NoThrow, Const] in {
//===--===//
+// Zicsr extension.
+//===--==
nemanjai wrote:
> I have always been unconvinced that these are a good idea to have / add
> significant value over using inline assembly. IIRC Arm has them but nobody
> uses them?
Is this a comment about the general concept of builtins to produce specific
instructions or about these specific
nemanjai wrote:
> > Individual implementations will provide different sets of CSR's and need a
> > way to read/write them. Of course, this can be done with inline asm, but
> > doing such things with inline asm has its limitations (no error checking,
>
> Wouldn't the assembler error check the c
jrtc27 wrote:
I have always been unconvinced that these are a good idea to have / add
significant value over using inline assembly. IIRC Arm has them but nobody uses
them?
https://github.com/llvm/llvm-project/pull/85091
___
cfe-commits mailing list
c
@@ -20,6 +20,12 @@ class RISCVBuiltin :
TargetBuiltin {
let Attributes = [NoThrow, Const] in {
//===--===//
+// Zicsr extension.
+//===--==
topperc wrote:
> Individual implementations will provide different sets of CSR's and need a
> way to read/write them. Of course, this can be done with inline asm, but
> doing such things with inline asm has its limitations (no error checking,
Wouldn't the assembler error check the constant? Di
@@ -74,6 +74,21 @@ let TargetPrefix = "riscv" in {
} // TargetPrefix = "riscv"
+let TargetPrefix = "riscv" in {
+ // Zicsr
+ def int_riscv_csrr :
+DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty],
+ [IntrNoMem, IntrHasSideEffects,
ImmArg>]>;
@@ -20,6 +20,12 @@ class RISCVBuiltin :
TargetBuiltin {
let Attributes = [NoThrow, Const] in {
//===--===//
+// Zicsr extension.
+//===--==
nemanjai wrote:
Individual implementations will provide different sets of CSR's and need a way
to read/write them. Of course, this can be done with inline asm, but doing such
things with inline asm has its limitations (no error checking, if a user
attempts to wrap the asm in a function, they w
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
@llvm/pr-subscribers-clang
Author: Nemanja Ivanovic (nemanjai)
Changes
To facilitate proper range checking and better error messages if an attempt is
made to call these with non-litaral arguments, we provide builtins to emit the
read/writ
https://github.com/nemanjai created
https://github.com/llvm/llvm-project/pull/85091
To facilitate proper range checking and better error messages if an attempt is
made to call these with non-litaral arguments, we provide builtins to emit the
read/write CSR instructions.
>From 543086dd6a208527
26 matches
Mail list logo