On Tue, Jul 6, 2021 at 10:46 AM Hongtao Liu <crazy...@gmail.com> wrote: > > On Thu, Jul 1, 2021 at 9:04 PM Jakub Jelinek via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > On Thu, Jul 01, 2021 at 02:58:01PM +0200, Richard Biener wrote: > > > > The main issue is complex _Float16 functions in libgcc. If _Float16 > > > > doesn't > > > > require -mavx512fp16, we need to compile complex _Float16 functions in > > > > libgcc without -mavx512fp16. Complex _Float16 performance is very > > > > important for our _Float16 usage. _Float16 performance has to be > > > > very fast. There should be no emulation anywhere when -mavx512fp16 > > > > is used. That is why _Float16 is available only with -mavx512fp16. > > > > > > It should be possible to emulate scalar _Float16 using _Float32 with a > > > reasonable > > > performance trade-off. I think users caring for _Float16 performance will > > > use vector intrinsics anyway since for scalar code _Float32 code will > > > likely > > > perform the same (at double storage cost) > > > > Only if it is allowed to have excess precision for _Float16. If not, then > > one would need to (expensively?) round after every operation at least. > There may be inconsistent behavior between soft-fp and avx512fp16 > instructions if we emulate _Float16 w/ float . > i.e > 1) for a + b - c where b and c are variables with the same big value > and a + b is NAN at _Float16 and real value at float, avx512fp16 > instruction will raise an exception but soft-fp won't(unless it's > rounded after every operation.) > 2) a / b where b is denormal value and AVX512FP16 won't flush it to > zero even w/ -Ofast, but when it's extended to float and using divss, > it will be flushed to zero and raise an exception when compiling w/ > Ofast > > To solve the upper issue, i try to add full emulation for _Float16(for > all those under libgcc/soft-fp/, i.e. add/sub/mul/div/cmp, .etc), > problem is in pass_expand, it always try wider mode first instead of > using soft-fp > > /* 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. > So the key point is that the soft-fp and avx512fp16 instructions may > do not behave the same on the exception, is this acceptable? I think that's quite often the case for soft-fp. > BTW, i've finished a initial patch to enable _Float16 on sse2, and > emulate _Float16 operation w/ float, and it passes all 312 new tests > which are related to _Float16, but those units tests doesn't cover the > scenario I'm talking about. > > > > Jakub > > > > > -- > BR, > Hongtao
