On Tue, 6 Jul 2021, Richard Biener via Gcc-patches wrote: > > /* Look for a wider mode of the same class for which we think we > > can open-code the operation. Check for a widening multiply at the > > wider mode as well. */ > > > > if (CLASS_HAS_WIDER_MODES_P (mclass) > > && methods != OPTAB_DIRECT && methods != OPTAB_LIB) > > FOR_EACH_WIDER_MODE (wider_mode, mode) > > > > I think pass_expand did this for some reason, so I'm a little afraid > > to touch this part of the code. > > It might be the first time we hit this ;) I don't think it's safe for > non-integer modes or even anything but a small set of operations. > Just consider ssadd besides rounding issues or FP.
I think it's safe for basic arithmetic (+-*/), for IEEE floating-point arithmetic when the wider mode has significand more than twice as wide as the narrower one (given that the result is immediately converted back to the narrower mode, double rounding isn't an issue given such a constraint on the widths of the modes - and given that the wider mode has sufficient exponent range to avoid intermediate overflow / underflow as an issue as well). (The precise requirements on the width of the modes may depend on the operation in question. It's *not* safe for fused multiply-add, regardless of the widths in question; a software implementation of fmaf16 using float arithmetic could be quite simple, using round-to-odd like e.g. glibc's implementation of fmaf using double arithmetic, but "call fmaf then convert the result to _Float16" would be an incorrect implementation.) -- Joseph S. Myers jos...@codesourcery.com
