This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] fold_range_test like optimization on GIMPLE (PR tree-optimization/46309)
On Fri, Sep 30, 2011 at 2:44 PM, Jakub Jelinek <jakub@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
>