From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10981 invoked by alias); 10 Jun 2004 22:24:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10956 invoked by uid 48); 10 Jun 2004 22:24:06 -0000 Date: Thu, 10 Jun 2004 22:24:00 -0000 Message-ID: <20040610222406.10955.qmail@sourceware.org> From: "dann at godzilla dot ics dot uci dot edu" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040610171754.15911.dann@godzilla.ics.uci.edu> References: <20040610171754.15911.dann@godzilla.ics.uci.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/15911] DOM optimization not performed X-Bugzilla-Reason: CC X-SW-Source: 2004-06/txt/msg01346.txt.bz2 List-Id: ------- Additional Comments From dann at godzilla dot ics dot uci dot edu 2004-06-10 22:24 ------- Hmmm, adding -march=athlon shows the same problem on i386. The problem does not occur 0f -march=i386 is used. The difference between the 2 cases above appears in the .t03.original dump: For i386 the first "if" is translated to: if (x > 5555 && y <= 6665) the "&&" corresponds to a tree_andif_expr tree for -march=athlon it is translated to: if (#`truth_and_expr' not supported by pp_c_expression#) here a truth_and_expr tree is used. For i386 the && is transformed in cascading ifs, and DOM knows how to deal with that. For athlon the truth_and_expr is transformed to: T.0 = x > 5555; T.1 = y <= 6665; T.2 = T.0 && T.1; if (T.2) .... In this case DOM does not infere that if T.2 is true then T.0 and T.1 are also true. The question is, should "&&" be lowered to different trees depending on the target architecture? -- What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911