[GSoC-19] Implementing narrowing functions like fadd

[Tejas Joshi]

Hi all,
I have some doubts regarding narrowing functions. Functions like fadd
have different variants like fadd, faddl and daddl. These functions
differs from general floating point functions which have float and
long double argument types. These functions are defined in
builtins.def like floor, floorf and floorl with their respective
macros BUILT_IN_FLOOR, BUILT_IN_FLOORF and BUILT_IN_FLOORL. But for
fadd, fsub, fmul variants, float is not supposed to be one of the
argument types.

Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
normal, F and L variants which are assigned to respective fcode
built_in_function. This makes any function defined in builtins.def to
have F and L variants mandatory. How these narrowing functions are
supposed to be handled? Do we define another macro expansion like
CASE_MATHFN or have a manual case handling in mathfn_built_in_2?
Attached patch is what I have tried so far.

Thanks,
Tejas

On Wed, 10 Jul 2019 at 18:03, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Tejas Joshi <tejasjoshi9673@gmail.com> writes:
> > Hello.
> > I have added fadd variants in builtins.def. For fadd and faddl
> > variants, I had to introduce builtin function types in
> > builtin-types.def :
> >
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> > +                    BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
> > +                    BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
> >
> > and used them to define function in builtins.def. At this point, only
> > faddf variant is getting called by test program :
> >
> > int main ()
> > {
> >     double z = __builtin_faddf (3.5, 1.4);
> > }
> > faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
> > defined in builtin-types.def means I need not to introduce it. Why
> > fadd and faddl are not getting called in this patch? I don't find any
> > other place where these function types needs to be added.
>
> This is because of:
>
>   if (mode == arg0_mode
>       && real_cst_p (arg0)
>       && real_cst_p (arg1))
>
> in fold_const_call_1.  The reason for that check is that usually
> the format passed in to fold_const_call_sss applies to both arguments
> and the return type.  There's already an exception for CASE_CFN_NEXTTOWARD
> though.  I guess you'll need something similar here.
>
> Thanks,
> Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fadd.diff
Type: text/x-patch
Size: 4989 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20190723/bed6533b/attachment.bin>