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

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi Richard,

On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote:
> Tejas Joshi <tejasjoshi9673@gmail.com> writes:
> >> It's just a different name, nothing more, nothing less.  Because it is
> >> a different name it can not be accidentally generated from actual
> >> truncations.
> >
> > I have introduced float_narrow but I could not find appropriate places
> > to generate it for a call to fadd instead it to generate a CALL. I
> > used GDB to set breakpoints which hit fold_rtx and cse_insn but I got
> > confused with the rtx codes and passes which generate respective RTL.
> > It should not be similar to FLOAT_TRUNCATE if we want to avoid it
> > generating for actual truncations?
> 
> Please don't do it this way.  The whole point of the work is that this
> is a single operation that cannot be modelled as a post-processing of
> a normal double addition result.  It's a single operation at the source
> level, a single IFN, a single optab, and a single instruction.  Splitting
> it apart into two operations for rtl only, and making it look in rtl terms
> like a post-processing of a normal addition result, seems like it's going
> to come back to bite us.
> 
> In lisp terms we're saying that the operand to the float_narrow is
> implicitly quoted:
> 
>   (float_narrow:m '(plus:n a b))
> 
> so that when float_narrow is evaluated, the argument is the unevaluated
> rtl expression "(plus a b)" rather than the evaluated result a + b.
> float_narrow then does its own evaluation of a and b and performs a
> fused addition and narrowing on the result.

RTL isn't Lisp.  RTL doesn't have quotations.  RTL doesn't have
*evaluation*.

RTL is just a data structure that describes your program instructions.
A large part of what means what is system-specific.  Rounding of floating
point is not defined, for example.

And yes, various parts of GCC can manipulate RTL, doing substitution and
algebraic simplication and whatnot.  All within the rules of RTL.  And
that means nothing ever can "pass" a float_narrow, because there are no
rules that allow it to.

> No other rtx rvalue works like this.

A lot of unspecs are used like this, for example.

> Using float_narrow would also be inconsistent with the way we handle
> saturating arithmetic.  There we use US_PLUS and SS_PLUS rtx codes for
> unsigned and signed saturating plus respectively, rather than:
> 
>   (unsigned_sat '(plus a b))
>   (signed_sat '(plus a b))
> 
> Using dedicated codes might seem clunky.  But it's simple, safe, and fits
> the existing model without special cases. :-)

And you need many many more RTX codes, which you will not handle in
almost all places, because there are too many.


I agree this construct is not as nice as could be hoped for.  I don't
agree that 60 new RTX codes is an acceptable solution (or that that will
ever really work out, even).


It would be nice if somehow we could make a variant of RTL codes, so that
we could have nice and simple code that applies to all variants of some
code.  Not sure how that would work out.  Maybe we don't have to do this
very generically, how often will we need this anyway?

I have three examples so far:
1) Saturating arithmetic;
2) This float_narrow thing;
3) Ordered compares, that is, fp compares that set an exception on NaNs.

Something that works for all three would be nice!


Segher