Am 07.08.24 um 12:04 schrieb Amit Hiremath:
Hello Georg-Johann,
Thanks for the clarification. Actually, I do not want to use asm. If I
write sample c code like this:
So what part of my answer about GCC insns is unclear to you?
Johann
#include <math.h>
#include <stdio.h>
int main()
{
float angle1 = 3.1415926;
printf("sin(3.14) = %.2lf\n", sin(angle1));
return 0;
}
The compiler should emit this instruction to the concerned FPU part in
RISC-V. Is it possible this way? Since RISC-V does not have
instructions for sine, cosine, exp, etc. they are taken care of by
soft fp libraries. I guess I do not need to rename instructions?
Thanks,
-Amit
On Wed, Aug 7, 2024 at 3:11 PM Georg-Johann Lay <avr@xxxxxxxx
<mailto:avr@xxxxxxxx>> wrote:
Am 07.08.24 um 08:24 schrieb Amit Hiremath:
> Hello,
>
> I want to add custom single precision floating point sine,
cosine, exp
> instructions to risc-v gnu tool chain, and I have designed
hardware for
> this. I was going through tutorials on how to add custom
instructions at:
> https://pcotret.gitlab.io/riscv-custom/sw_toolchain.html
<https://pcotret.gitlab.io/riscv-custom/sw_toolchain.html> after adding
> custom instructions, I think one has to use asm volatile macro to use
> custom instructions in C. Is there anyway where one do not need
to use this
Hi, There is no need for asm volatile, asm is enough because there are
no side effects other than the computation. And for compile-time
constants, there is no need for asm, like in:
if (__builtin_constant_p (sinf (x))
y = sinf (x);
else
__asm ("..." : "=r" (y), ...);
> macro? I would like the compiler to automatically map to custom
> instructions in the risc-v processor, like how it will map to fadd.s,
> fmul.s instructions, where one does not need to use asm volatile
macro.
This would be a new insn named "sinsf2" for sinf. The "sf" stands for
SFmode (single float, e.g. IEEE single).
https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html
<https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>
You can have a look at how other backends are doing it, for example
grep the GCC sources:
$ grep -rn '"sin' gcc/config | grep -v single
which yields a dozen or so hits, for example nvptx:
(define_insn "sinsf2"
[(set (match_operand:SF 0 "nvptx_register_operand" "=R")
(unspec:SF [(match_operand:SF 1 "nvptx_register_operand" "R")]
UNSPEC_SIN))]
"flag_unsafe_math_optimizations"
"%.\\tsin.approx%t0\\t%0, %1;")
(I don't know whether unspec is still required today. rtl.def
doesn't seen to have sin, so yes, you need an unspec.)
The insn condition is presumably because the nvptx sinf is not
fully IEEE compliant. When sinf is available on some devices
but not on others, the insn condition would express that, too.
The constraints would be the same like in an asm. When there
are no appropriate constraints and the asm is using local
register variables, then you'll have to add new register
constraints and register classes that describe which
hard registers are appropriate for the new instruction.
(But notice that there is an upcoming feature that allows
single hard register as a constraint like "{r42}".)
Finally, as you also have cosf, you would also add insns
for cossf2 and sincossf3.
HTH
Johann
> I asked in riscv gnu tool chain forum about this issue:
> https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1526
<https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1526> they
> suggested that I ask this query in the gcc forum.
>
> Can you please guide me?
>
> Many Thanks,
> -Amith
