> On Jun 27, 2016, at 12:41 PM, Richard Sandiford <rdsandif...@googlemail.com> > wrote: > > Joseph Myers <jos...@codesourcery.com> writes: >> On Wed, 22 Jun 2016, Bill Schmidt wrote: >>> The fact that I hook this built-in directly to a pattern named infkf1 >>> doesn't seem to preclude anything you suggest. I named it this way >>> on the off-chance that inf<m>1 becomes a standard pattern in the >>> future, in which case I want to generate this constant. We can >>> always use gen_infkf1 to reuse this code in any other context. I'm >>> not understanding your objection. >> >> That expander pattern is not useful given a target-independent built-in >> __builtin_inff128, since it will never be used except by a built-in >> function specifically associated with it. >> >> I don't know what code will be generated for a use of _Float128 infinity, >> from the target-independent code - or, right now, for a use of >> (__float128) __builtin_inf (). But if it's not the code you want, any >> reasonable fix would not be restricted to the case where __builtin_inff128 >> () is used - it would work equally well for any case where that constant >> bit-pattern is wanted in VSX registers. > > Yeah, I don't think we should have named patterns to generate constants. > We should send the constant through the normal move patterns and make > the expander or move define_insns handle them appropriately.
Agreed. We'll plan on working the various interesting constants into the handling of the move insns. Bill > > Thanks, > Richard >
