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. For the future - could rs6000 and x86 use the same compile options to handle reciprocals? Uros.
