https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-04-22
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> fold guards it with !HONOR_SIGNED_ZEROS && !HONOR_NANS
> (fold_cond_expr_with_comparison).
Those are both needed for SMIN/SMAX to make sense at all (they are
undefined otherwise).
> I think the flag_unsafe_math_optmizations
> check is bogus.
The transform violates IEEE rules, so this flag is required.
It's not clear how much the overlap between signed-zeros etc. with this
flag is. That's not something we can fix in this PR :-)
> Note we now have fmax/fmin named patterns that can be used unconditionally
> but I guess using expanders during RTL simplification can be tricky.
Yes, and they cannot catch all cases at all.
> Note also we as of today generally avoid doing "much" with FP math on the
> RTL side and IMHO we should continue to do so. IMHO the transform belongs
> on the GIMPLE side where we already do it.
There are still very many cases that aren't found (and sometimes cannot
be found) before rtl. All higher level things should be done in gimple,
yes, but *none* of the low-level things!
