> On Jun 22, 2016, at 6:27 PM, Joseph Myers <jos...@codesourcery.com> wrote: > > On Wed, 22 Jun 2016, Bill Schmidt wrote: > >> Hi Joseph, >> >> That's indeed preferable for the long term -- given how close we are to the >> cutoff for 6.2, though, I'm worried about adding any new dependencies for >> getting this upstream. I'd suggest that we go ahead with reviewing this >> patch in the short term, and I'll be happy to work with you later on getting >> the impedance matching right when they become arch-neutral. > > The architecture-independent built-in functions really aren't hard. See > this patch, on top of my main _FloatN / _FloatNx patch. (Not written up > or fully regression-tested, and I want to add more test coverage, but it > seems to work.) To keep this patch minimal I didn't include updates to a > few case statements only needed for optimization, e.g. in > tree_call_nonnegative_warnv_p, but when those are changed you get > optimizations automatically for these functions that would be harder to > get with anything architecture-specific.
I understand that this is what we want for GCC 7. My current concern is to get my patch included in GCC 6.2, where I can't be polluting common code. To get it accepted there, I first need this code approved in mainline. So I am quite willing to move to the architecture-independent ones later, but for now I don't see that I have any choice but to seek approval for the purely arch-dependent one. > > Regarding your patch: > > (a) for GCC 6 (supposing my patch is used for trunk), it's missing > documentation for the new functions (this patch has documentation for the > architecture-independent functions); A very good point -- I totally forgot about this, and will have to add it. > > (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. Thanks, Bill
