Hello.
I have been trying to write a basic pattern taking all the suggestions
you both have mentioned. The same patch is attached here, but I cannot
see call to :

float
foo (double x, double y)
{
    return __builtin_fadd (x, y);
}
being expanded to any instruction, at least a simple one, using
-fno-builtin-fadd (and also -mhard-float?). It always stays "bl fadd".
What am I missing here?

> (POWER8 and later) on.  (The result if OE=1 or UE=1 is undefined).  (See
> 4.3.5.1 in the ISA).

4.3.5.1 in the ISA says that single precision arithmetic instructions
perform operation in double format and coerces the result in single
format. Can fadd be considered as this type of instruction or do I
need to perform add in DFmode and then use "instruction provided to
explicitly convert double format operand in FPR to single format."?

Thanks,
Tejas


On Fri, 9 Aug 2019 at 04:39, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 8 Aug 2019, Segher Boessenkool wrote:
>
> > These current patterns all take the same mode for all inputs and outputs
> > (that's what <mode>3 indicates, say, fadddf3).  You will need to define
> > something that takes two SFs in and produces a DF.  That cannot really
>
> For example, md.texi describes standard patterns such as mulhisi3 that
> multiply two HImode values and produce an SImode result (widening integer
> multiply).
>
> Using a similar naming pattern, you might have a pattern adddfsf3 that
> multiplies two DFmode values and produces an SFmode result (or you could
> call it something like add_truncdfsf3 if you wish to emphasise the
> truncation involved, for example).  Similarly addtfsf3 that multiplies
> TFmode and produces an SFmode result, and so on.  Of course these names
> need documenting (and you need corresponding RTL for them to generate that
> distinguishes the fused add+truncate from the different RTL for separate
> addition and truncation with double rounding).  In cases where long double
> and double have the same mode, the daddl function should use the existing
> adddf3 pattern.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com