[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > I've screwed up the real_value_negate calls, they need to assign the result.
> > 
> > Anyway, yet another option would be for cdce to ask the ranger if the sqrt
> > argument can be smaller than -0.0 (and only if it can, emit the comparison).
> > Then we don't need to deal with removing the comparison again.
> > Of course, such removals might be still useful for user code.
> 
> even checking the global range from cdce at this point should show that its
> >= -0.0...

Without larger changes in tree-call-cdce.cc, perhaps we could change
gen_one_condition to check the global or even non-global frange (but in the
latter case the question is at what stmt) and if the range indicates that tcode
of arg against (float_type) lbub (aka lbub_real_cst) is always true or always
false, simply emit an always true or always false condition (though the domain
ranges aren't exact but rounded up/down to integers and I think even there is
sometimes an off by one conservatively, so probably only always true
conditions)
rather than actual arg comparison.  Even better would be not to emit any and/or
propagate a stmt to it, but am not sure about either (the code treats nconds ==
0 differently and there are separators in between sometimes; and for stmt, it
uses some code for better placement of a check, but not sure if say a range
could be true on the sqrt etc. call and then not on the placement of the
condition which it picks).
In any case, not much familiar with the range_of_expr etc. APIs.