On Sat, Sep 3, 2011 at 11:11 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Sat, Sep 3, 2011 at 5:42 PM, Michael Matz <m...@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.
Some relevant PRs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47989 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702 Uros.
