Hello. > fold_const_fadd), for example I am not sure what the return values are > supposed to mean, and add a run-time testcase(s) and I'd say you are > done for now
I modeled real_fadd function on a similar function, real_nextafter which would take three arguments. Just as overflow and underflow conditions are handled there, I thought similarly if exact/inexact and overflow/underflow conditions would be handled by fold_const_fadd for real_fadd. As these conditions are still need to be addressed (so current function is prototypish), is real_nextafter a good model to refer? > I am not sure I understand your question, you have used real_convert in > real_fadd and it seems to be doing exactly that? As you know I am not Looking at different comments where real_convert is used, I guessed it formats GCC's floating point format to a target format rather than converting to return type. Its still unclear to me but its good if it does convert to return type like it seems. I am working on these conditions now and will try to come up with testcases. Thanks, Tejas On Mon, 29 Jul 2019 at 22:47, Martin Jambor <mjam...@suse.cz> wrote: > > Hi, > > On Sat, Jul 27 2019, Tejas Joshi wrote: > > Hello. > > > >>> You'll need something different from CASE_MATHFN - these are a different > >>> kind of functions that need handling in a different way, because they are > >>> parametrized over certain *pairs* of types, rather than over a single > >>> type. > >> first phase, please just directly test for in the code for > >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process > >> those here to get a prototype working. When you add support for more > > > > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this > > following patch and function is getting folded. > > good. Please add comments to functions which miss them (real_fadd and > fold_const_fadd), for example I am not sure what the return values are > supposed to mean, and add a run-time testcase(s) and I'd say you are > done for now - after you implement fsub, fmul and fdiv(?) you might want > to re-structure some common bits to make the code prettier. > > > My question is that how the addition and narrowing should be performed > > (is it ok to use do_add for addition?). > > I don't see a reason why it would not be. > > > As functions in real.c does > > not operate on any specific precision, just defining the return type > > as float would do the trick? Or do I need to make trailing > > out-of-precision bits zero? If yes, having functions like > > double_to_float would then be useful or such functions already exist > > to do the conversion? > > I am not sure I understand your question, you have used real_convert in > real_fadd and it seems to be doing exactly that? As you know I am not > too familiar with this area of gcc but reading the code suggests that > and a simple debugging session seems to confirm that (some unimportant > gdb output omitted): > > ---------------------------------------------------------------------- > $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args > GNU gdb (GDB; openSUSE Tumbleweed) 8.3 > Copyright (C) 2019 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > > (gdb) b real_fadd > Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line > 5100. > (gdb) r > Starting program: > /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet > fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 > -auxbase fadd-fold -Ofast -o fadd-fold.s > > Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, > y=0x7ffff7800080) > at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100 > 5100 do_add (r, x, y, 0); > (gdb) n > 5101 if (fmt) > (gdb) p *r > $1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, > sig = {0, 0, > 10549231767152649216}} > (gdb) p/x r->sig[2] > $2 = 0x9266666666666400 > (gdb) n > 5102 real_convert (r, fmt, r); > (gdb) > 5103 return false; > (gdb) p/x r->sig[2] > $3 = 0x9266660000000000 > ---------------------------------------------------------------------- > > Thanks, > > Martin > >
