Re: [RFC] Split -mrecip

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Sat, Sep 03, 2011 at 02:44:07PM +0200, Uros Bizjak wrote:
> On Wed, Aug 31, 2011 at 6:16 PM, Michael Matz <matz@suse.de> wrote:
> 
> > I'd like to have tighter control over the individual situations that
> > -mrecip handles, and I think the user might appreciate this too. ?Hence
> > I've introduced four new target options -mrecip-div, -mrecip-sqrt,
> > -mrecip-vec-div and -mrecip-vec-sqrt. ?I've redefined -mrecip to be
> > equivalent to using those four options together. ?In addition one can
> > selectively disable some part via -mrecip -mno-recip-vec for instance.
> >
> > I was split mind about the approach, I could also have done like rs6000
> > (-mrecip=<csv list>) with the disadvantage of having to write an own
> > parser as our opt framework can't deal with comma separated lists of
> > masks. ?With the approach I chose our opt framework gets most of the work
> > done.
> >
> > 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.

It is possible that the vector recip. might not be optimal.

> For the future - could rs6000 and x86 use the same compile options to
> handle reciprocals?

As long as the current ppc flags continue to work, I think it would be useful
to have them use the same standard options, much like we do for fma now.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com	fax +1 (978) 399-6899