On Wed, 20 Jun 2012, Richard Guenther wrote:
> On Sun, Jun 10, 2012 at 4:16 PM, Marc Glisse <
marc.glisse@...> 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).
> At least
>
> + if (inv & 1)
> + lcompcode2 = COMPCODE_TRUE - lcompcode2;
>
> looks as if it were not semantically correct - you cannot simply invert
> floating-point comparisons (see the restrictions invert_tree_comparison
> has).
I don't remember all details, but I specifically thought of that, and the
trapping behavior is handled a few lines below.
--
Marc Glisse
