> On Jun 22, 2016, at 8:10 PM, Bill Schmidt <wschm...@linux.vnet.ibm.com> wrote: > >> On Jun 22, 2016, at 6:27 PM, Joseph Myers <jos...@codesourcery.com> wrote: >> >> (b) for trunk, having an insn pattern infkf1 for a built-in function that >> loads a constant is not appropriate (other insn patterns to optimize the >> architecture-independent built-in functions may well be appropriate). >> Rather, if there is a particularly efficient way of generating code to >> load a certain constant, the back end should be set up to use that way >> whenever that constant occurs (more generally, whenever any constant to >> which that efficient way applies occurs) - including for example when it >> occurs from folding arithmetic, say (__float128) __builtin_inff (), not >> just from __builtin_inff128 (). > > 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.
Though perhaps your point is the specific use of KF here, which is inconsistent and should be fixed. The mode should be "whichever of TF and KF is IEEE-128" as elsewhere. I'll fix that. Probably this pattern should be moved over to rs6000.md also, where the fabs and copysign support are. Bill > > Thanks, > Bill
