On Fri, Sep 30, 2011 at 2:44 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Sep 30, 2011 at 02:26:40PM +0200, Richard Guenther wrote:
>> > It is boolean only in some testcases, the is_bool stuff discussed at the
>> > beginning above was originally just an early return
>> > if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
>> > return;
>> > before the loop, but it turned out that often the type of the | operands
>> > is integer, with either bool casted to integer, or with the type of EQ_EXPR
>> > etc. being integer instead of bool.
>>
>> Really? The type of EQ_EXPR should be always either BOOLEAN_TYPE
>> or INTEGRAL_TYPE_P with TYPE_PRECISION == 1. That's what
>> the gimple verifier checks. Or do you mean that fold introduces these
>> kind of types during range-test simplification?
>
> Consider:
>
> int
> f1 (int a, int b)
> {
> int v1 = (a <= 64);
> int v2 = (a == 66);
> int v3 = (a == 67);
> int v4 = (a == 65);
> return b || v1 || v2 || v3 || v4;
> }
>
> int
> f2 (int a, int b)
> {
> int v1 = (a <= 64);
> int v2 = (a == 66);
> int v3 = (a == 67);
> int v4 = (a == 65);
> return b | v1 | v2 | v3 | v4;
> }
>
> in *.dse1 f1 is:
> D.2744_2 = a_1(D) <= 64;
> v1_3 = (int) D.2744_2;
> D.2745_4 = a_1(D) == 66;
> v2_5 = (int) D.2745_4;
> D.2746_6 = a_1(D) == 67;
> v3_7 = (int) D.2746_6;
> D.2747_8 = a_1(D) == 65;
> v4_9 = (int) D.2747_8;
> D.2749_11 = b_10(D) | v1_3;
> D.2750_12 = D.2749_11 | v2_5;
> D.2751_13 = D.2750_12 | v3_7;
> D.2752_14 = D.2751_13 | v4_9;
> D.2753_15 = D.2752_14 != 0;
> D.2748_16 = (int) D.2753_15;
> return D.2748_16;
> and f2 is:
> D.2735_2 = a_1(D) <= 64;
> v1_3 = (int) D.2735_2;
> D.2736_4 = a_1(D) == 66;
> v2_5 = (int) D.2736_4;
> D.2737_6 = a_1(D) == 67;
> v3_7 = (int) D.2737_6;
> D.2738_8 = a_1(D) == 65;
> v4_9 = (int) D.2738_8;
> D.2740_11 = b_10(D) | v1_3;
> D.2741_12 = D.2740_11 | v2_5;
> D.2742_13 = D.2741_12 | v3_7;
> D.2739_14 = D.2742_13 | v4_9;
> return D.2739_14;
> In both cases, the arguments of BIT_IOR_EXPR are ints
> and init_range_entry needs to go through the casts to reach the
> comparison (on which it figures out that the value is really 0/1,
> well, in this case already on the rhs of the cast, as it is _Bool).
Ah, indeed. I'll have a look at the updated patch.
Richard.
> Jakub
>
