This section I am not clear:
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), ...);
It seems to me that one still needs to use __asm macro after adding new
instruction. But what I am asking is, 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;
}
I am expecting the compiler should emit 'sin instruction' to RISC-V
processor without __asm micro, is it possible the above sample code way?
On Wed, Aug 7, 2024 at 4:24 PM Georg-Johann Lay <avr@xxxxxxxx> wrote:
>
>
> 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
> >
>
