andykaylor wrote: Providing a bit more context here, the change to remove the finite-math-only assumption from `-ffp-model=fast` is intended to avoid problems like https://github.com/llvm/llvm-project/issues/69089. In that case, more aggressive optimizations based on the `ninf` fast-math flag (which is currently set with fp-model=fast) caused the povray benchmark to fail with options where it had previously been working. I have gotten reports of many similar problems from customers of a downstream compiler that I support.
The change to the complex arithmetic handling has similar motivation, but I don't have an example bug report to share. The current implementation of `-ffp-model=fast` represents complex division using the basic mathematical formula with no protection against overflow of intermediate computations and no special handling for corner cases described in the C standard for mixing NaN and Inf components. The change I am proposing avoids intermediate overflow in most cases without significantly reducing performance but still does not handle the mixed NaN/Inf corner case, which I believe is rare. Because the general "finite-math-only" flags aren't set, users can implement handling to avoid the corner case without paying the full performance penalty on every complex division. And, of course, the -fcomplex-arithmetic option is available for anyone who wants the extra handling to be generated by the front end. https://github.com/llvm/llvm-project/pull/100453 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
