Re: [Patch] PR 51938: extend ifcombine

[Marc Glisse <marc dot glisse at inria dot fr>]

On Wed, 20 Jun 2012, Marc Glisse wrote:

> On Wed, 20 Jun 2012, Richard Guenther wrote:
>
> > On Sun, Jun 10, 2012 at 4:16 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> > > Hello,
> > >
> > > currently, tree-ssa-ifcombine handles pairs of imbricated "if"s that share
> > > the same then branch, or the same else branch. There is no particular 
> > > reason
> > > why it couldn't also handle the case where the then branch of one is the
> > > else branch of the other, which is what I do here.
> > >
> > > Any comments?
> >
> > The general idea looks good, but I think the patch is too invasive.  As far
> > as I can see the only callers with a non-zero 'inv' argument come from
> > ifcombine_ifnotorif and ifcombine_ifnotandif (and both with inv == 2).
> > I would rather see a more localized patch that makes use of
> > invert_tree_comparison to perform the inversion on the call arguments
> > of maybe_fold_and/or_comparisons.
> >
> > Is there any reason that would not work?
>
> invert_tree_comparison is useless for floating point (the case I am most 
> interested in) unless we specify -fno-trapping-math (writing this patch 
> taught me to add this flag to my default flags, but I can't expect everyone 
> to do the same). An issue is that gcc mixes the behaviors of qnan and snan 
> (it is not really an issue, it just means that !(comparison) can't be 
> represented as comparison2).

Actually, what would you think of 
s/flag_trapping_math/flag_signaling_nans/
in invert_tree_comparison? Are there other possible ways a<b can trap than 
having a sNaN for a or b?

--
Marc Glisse