From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-292234-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10408 invoked by alias); 19 May 2011 17:53:07 -0000
Received: (qmail 10398 invoked by uid 22791); 19 May 2011 17:53:06 -0000
X-SWARE-Spam-Status: No, hits=-1.0 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST
X-Spam-Check-By: sourceware.org
Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 May 2011 17:52:52 +0000
Received: by qwh5 with SMTP id 5so1678400qwh.20        for <gcc-patches@gcc.gnu.org>; Thu, 19 May 2011 10:52:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.51.214 with SMTP id e22mr2587541qcg.156.1305827571811; Thu, 19 May 2011 10:52:51 -0700 (PDT)
Received: by 10.229.33.209 with HTTP; Thu, 19 May 2011 10:52:51 -0700 (PDT)
In-Reply-To: <BANLkTik3EpJHZvquEt_A_jMHmGh=pYJgQA@mail.gmail.com>
References: <BANLkTik+c=A4xqqMTXphcP7_b1KTptw71w@mail.gmail.com>	<BANLkTimPoDbbBrXAiN5VpjWNgoOt7DJuqw@mail.gmail.com>	<BANLkTimbbzNW+zCH-Rb4LCEoXYEpgA+EFQ@mail.gmail.com>	<BANLkTik6dcs8LZCuCs4qaRL9wDeNaDBcog@mail.gmail.com>	<BANLkTin3fJ8PCbvzZXkRrt8O99-hVzqdQw@mail.gmail.com>	<BANLkTinR78EEO6vm5zQdysW_4ad3ettfqA@mail.gmail.com>	<BANLkTik0=e+PuUR4-7PUe_E6JiNZn2VBMQ@mail.gmail.com>	<BANLkTimM_BZJKXirZg1DwGM=h7qJMKNxkQ@mail.gmail.com>	<BANLkTim+jQ9N56pC8Ke2Q3WeAi=VOnEvVw@mail.gmail.com>	<BANLkTinfkPLm_5gY=RYkdW_udEWYg59t4g@mail.gmail.com>	<BANLkTik3EpJHZvquEt_A_jMHmGh=pYJgQA@mail.gmail.com>
Date: Thu, 19 May 2011 19:20:00 -0000
Message-ID: <BANLkTimS5ipdfUhyOBzqXi9wqrsWHr0n8w@mail.gmail.com>
Subject: Re: [patch tree-ssa-reassoc.c]: Better reassoication for comparision and boolean-logic
From: Kai Tietz <ktietz70@googlemail.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-05/txt/msg01405.txt.bz2

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.

Regards,
Kai