Hello Georg-Johann,
Thanks for the clarification. Actually, I do not want to use asm. If I
write sample c code like this:
#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> 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 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
>
> 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 they
> > suggested that I ask this query in the gcc forum.
> >
> > Can you please guide me?
> >
> > Many Thanks,
> > -Amith
>
