On Tue, Aug 11, 2020 at 11:32:32PM -0400, Michael Meissner wrote: > > > + /* See if we can use the ISA 3.1 min/max/compare instructions for IEEE > > > + 128-bit floating point. At present, don't worry about doing > > > conditional > > > + moves with different types for the comparison and movement (unlike > > > SF/DF, > > > + where you can do a conditional test between double and use float as > > > the > > > + if/then parts. */ > > > > Why is that? That makes the code quite different too (harder to > > review), but also, it could just use existing code more. > > It is a combinatorial expansion problem.
Yes, we now have twice the code! > To grow this for IEEE 128, you would need two iterators, each with 4 elements > (DF, SF, KF, and optionally TF). Thus you would need 16 patterns to represent > all of the patterns. I can do this, I just didn't think it was worth it. No, you need *one* pattern instead of two! (It doesn't matter much what happens behind the scenes we already have many thousands of patterns, a few more or less doesn't matter). > In addition, it becomes more involved due to constraints. Currently for SF/DF > you essentially want to use any vector register at this point (when I added it > in 2016, there was still the support for limiting whether SF/DF could use the > Altivec registers). But for IEEE 128-bit fp types, you want "v" for the > registers used for comparison. You might want "v" for the contitional move > result, or you might want "wa". We handle this same problem with attributes usually. > I looked at combining the SF/DF and IEEE 128-bit cases, but it was becoming > too > complex to describe these cases. It is doable, but it makes the diffs even > harder to read. (The end code is what matters, not the diffs) I don't see why. You could be right of course, but please convince me. > > So why do we want the asymmetrical xsmincqp instead of xsminqp? This > > should be documented at the very least. (We also should have min/max > > that work correctly without -ffast-math, of course :-( ). > > We don't have an xsminqp or xsmaxqp instruction in power10. We only have > xsmincqp and xsmaxcqp instructions. Oh wow, I hadn't noticed that before (or I had pushed it all the way back, like any other bad dream). Eww. So we are limited to only generating this insn with -ffast-math. Bah. (smin/smax on float cannot be used without fast math). Segher
