On Wed, Jan 25, 2023 at 7:05 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > This boils down to a single place where we are trying to do things with > relations in ranger that are simply not safe when we need to honor NANs. > > I think we can avoid all the other shuffling of relations, and simply > not perform this optimization when it comes to floats. > > The case the routine handles is: > > c_2 = a_6 > b_7 > c_3 = a_6 < b_7 > c_4 = c_2 && c_3 > > c_2 and c_3 can never be true at the same time, Therefore c_4 can always > resolve to false based purely on the relations. > > > Range-ops is unable to do this optimization directly as it requires > examining things from outside the statement, and is not easily > communicated a simple relation to operator_logical_and. > > This routine proceeds to look at the definitions of c_2 and c_3, tries > to determine if there are common operands, and queries for any relations > between them. If it turns out there is something, depending on whether > its && or || , we use intersection or union to determine if the result > of the logical operation can be folded. If HONOR_NANS is true for the > float type, then we cannot do this optimization, and bail early. > > At this point I do not think we need to do any of the other things > proposed to relations, so we don't need either of the other 2 patches > this release. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
+ if (HONOR_NANS (TREE_TYPE (ssa1_dep1))) + return; would that rather be !(range-includes-nan (ssa1_dep1) || range-includes-nan (ssa1_dep2) || ..)? That said, if the other 2 patches fix some latent issues in the new frange code I'd rather have them fixed. Richard. > > Andrew
