Hi! On Tue, Apr 28, 2020 at 12:25:04AM -0300, Alexandre Oliva wrote: > On Apr 24, 2020, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > >> > since all the top bits are zeros always, it will always be a subnormal > >> > number, so all comparisons will work as expected / wanted. > >> > >> *nod*, as long as there's no trapping on subnormals. > > > There isn't :-) I did say this isn't clean at all, just *happens* to > > work, right? :-) > > I hope you don't mind my using the union in the testcase, that was > otherwise unused, to IMHO improve on that, then ;-)
That is fine, makes things clearer and more obviously correct. > > Could you open one? > > Sure, PR94812 Thanks! > But part of the FPSCR that mffsl (emulated with mmfl or not) copies to s/mmfl/mffs/ > the least desirable thing during debugging > is to find out, after hours of investigation, that you were led down > the wrong path by incorrect information. If you think that is the worst that can happen... :-P > Yet another issue is that the test assumed the mmfs bits that are not s/mmfs/mffs/ > + rtx tmp1 = gen_reg_rtx (DFmode); > + > + /* The mffs instruction reads the entire FPSCR. Emulate the mffsl > + instruction using the mffs instruction and masking off the bits > + the mmsl instruction actually reads. */ > + emit_insn (gen_rs6000_mffs (tmp1)); s/mmsl/mffsl/ I'd just say "and masking the result". Okay for trunk with such tweaks. Thank you! Also okay for the 9 branch, after waiting to see if any fallout appears. Segher
