Re: [patch tree-ssa-reassoc.c]: Better reassoication for comparision and boolean-logic

[Richard Guenther <richard.guenther@gmail.com>]

On Thu, May 19, 2011 at 7:52 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> To illustrate in which scenario code in tree-ssa-forwprop doesn't help
> is binop-tor4.c
>
> w/o this patch we get
>
>
> foo (int a, int b, int c)
> {
>  int e;
>  int d;
>  int D.2701;
>  _Bool D.2700;
>  _Bool D.2699;
>  _Bool D.2698;
>  _Bool D.2697;
>  _Bool D.2696;
>  int D.2695;
>
> <bb 2>:
>  D.2695_3 = b_2(D) | a_1(D);
>  d_4 = D.2695_3 != 0;
>  D.2696_5 = a_1(D) == 0;
>  D.2697_6 = b_2(D) == 0;
>  D.2698_7 = D.2697_6 | D.2696_5;
>  D.2699_9 = c_8(D) != 0;
>  D.2700_10 = D.2698_7 | D.2699_9;
>  e_11 = (int) D.2700_10;
>  D.2701_12 = e_11 | d_4;
>  return D.2701_12;
> }
>
> Of interest is here  D.2701_12, which doesn't have a type sinking.
> This is caused by
>
>  D.2695_3 = b_2(D) | a_1(D);
>  d_4 = D.2695_3 != 0;
>
> which is a comparison result with implicit integer cast. So maybe the
> solution here could be to first doing boolification of comparison in
> gimplifier. By this, the code for type-sinking in my patch could go
> away.

Well, forwprop either needs to be teached to handle this different kind
of widening

  d_4 = D.2687_3 != 0;
  e_11 = (int) D.2692_10;
  D.2694_12 = e_11 | d_4;

or indeed comparisons should also be boolified (which I think they
should - they are also predicate producers).

Still whether sinking or hoisting the stuff is the right thing, reassoc
is not the place to do it.

Richard.