On Thu, May 19, 2011 at 7:52 PM, Kai Tietz <ktiet...@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.
