This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Split -mrecip
On Sat, Sep 3, 2011 at 5:42 PM, Michael Matz <matz@suse.de> wrote:
>> > I've decided to not use four new bits from target_flags, and instead
>> > created a new mask (recip_mask). ?Four bits would have fit in target
>> > bits right now, ?but in the future we might want to add more
>> > specialization, like modes for which the reciprocals are active.
>> >
>> > What do you think?
>>
>> These new flags looks like a nice addition, but I wonder, why we need
>> separate options to handle vector recip. A vector rsqrt or rdiv is
>> generated automatically in the same way as scalar rsqrt or rdiv is
>> generated, so IMO, -mrecip-sqrt and -mrecip-div should be enough.
>
> No, the difference does matter. ?Using reciprocal estimates for scalar
> divs often results in errors in benchmarks because those sometimes are
> used to feed integer conversions for either index calculations or
> printouts. ?The small rounding errors with the reciprocals lead to
> incorrect outputs then. ?Context where the div can be vectorized often
> don't have this problem (they're then used purely for calculations over
> arrays of float data). ?For instance spec2006 and polyhedron break with
> -mrecip purely because of the scalar reciprocals, but work with only
> vectorized ones. ?I.e. users really want to differ between both.
I agree with your analysis.
> Also, when this patch goes in I plan to submit another one that activates
> vectorized rcp/rsqrt under -ffast-math already (that's what ICC happens to
> do too).
Great! In the past, we tried to use -mrecip with -ffast-math. IIRC,
polyhedron broke on scalar rdiv and spec2006 broke on rsqrt. Taking
into account your analysis above, using separate options and
activating vectorized ones for -ffast-math makes much sense.
>> For the future - could rs6000 and x86 use the same compile options to
>> handle reciprocals?
>
> I'd guess so. ?rs6000 uses a hand-written comma-splitter, which we could
> reuse.
Perhaps rs6000 could adopt our approach in addition to its
comma-splitter? OTOH, whatever is more convenient, I don't care that
much. I have CC'd rs6000 maintainer for his opinion.
Uros.