On Sat, Sep 03, 2011 at 02:44:07PM +0200, Uros Bizjak wrote: > On Wed, Aug 31, 2011 at 6:16 PM, Michael Matz <m...@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 meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
