This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expansion of narrowing math built-ins into power instructions


Hi!

> As far as I understand that flag should set the behaviour of the fadd
> function, not the __builtin_fadd one.  So I don't know.

According to ISO/IEC TS 18661, I am supposed to implement the fadd
variants for folding and expand them inline, that take double and long
double as arguments and return
addition in appropriate narrower type, float and double. As far as I
know, we use __builtin_ to call the internal functions? I do not know
which the only fadd function is.

> double precision one.  But instead you want to add two double precision
> numbers, producing a single precision one?  The fadds instruction fits

Yes.

> well to that, but you'll have to check exactly how the fadd() function
> should behave with respect to rounding and exceptions and the like.

In Joseph's initial mail that describes what should be carried out in
the course of project, about rounding and exceptions. I have strictly
followed this description for my folding patch :

* The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
from most other built-in math.h functions because the return type is
different from the argument types.  You could start by adding them to
builtins.def similarly to roundeven (with new macros to handle adding such
functions for relevant pairs of _FloatN, _FloatNx types).  These functions
could be folded for constant arguments only if the result is exact, or if
-fno-rounding-math -fno-trapping-math (and -fno-math-errno if the result
involves overflow / underflow).

Thanks,
Tejas


On Sat, 10 Aug 2019 at 22:16, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> > 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?
>
> As far as I understand that flag should set the behaviour of the fadd
> function, not the __builtin_fadd one.  So I don't know.
>
> > > (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."?
>
> A single precision add is "fadds".  It rounds its result to single
> precision.
>
> I'm lost what the exact semantic of the wanted fadd() function are.
> I thought you wanted to add two single precision numbers, producing a
> double precision one.  But instead you want to add two double precision
> numbers, producing a single precision one?  The fadds instruction fits
> well to that, but you'll have to check exactly how the fadd() function
> should behave with respect to rounding and exceptions and the like.
>
>
> Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]