Re: float "op-and-halve"

Re: float "op-and-halve"

[Richard Henderson]

On 10/05/2011 07:16 PM, David Miller wrote:
> From: David Bremner <dbremner@gmail.com>
> Date: Wed, 5 Oct 2011 19:08:41 -0700
> 
>> What about treating these instructions as fused multiply-adds with
>> constant arguments?
> 
> Richard Henderson (CC:'d) chatted with me the other day about this and
> made the same initial suggestion, but after thinking about it some
> more he concluded that this would not work currently.
> 
>> The reciprocal of 2 is exactly represented, so there's no loss of
>> precision. The x86 backend uses a similar method to model the x87
>> instructions that load various constants, see
>> standard_80387_constant_p.
> 
> Indeed, it sounds compelling.
> 
> Richard, what was the exact reason doing this won't work?  I don't
> quite remember the details.

We were talking about a representation of 

	(fma (plus a b) 0.5 -0.0)

Problems with this arise when the compiler propagates constants into
both A and B and tries to fold this.  The PLUS will be simplified
independently of the FMA.  Which means that the compiler evaluation
of the expression will see overflow when the insn won't.

We'd have to invent a new "fp-add-and-multiply" rtx code taking two
addition operands and a multiplication operand in order to get the
compiler to fold this properly.  Which doesn't seem that worthwhile
given that Sparc is the only target I've seen with this feature.

OTOH, we do have the target hook whereby we can simplify the builtin
during gimple optimization.  And unless our gimple optimizers are 
totally falling over should take care of all of the folding possibilities.

You'd need to use the MPFR routines to properly evaluate this, Dave.


r~