From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10893 invoked by alias); 25 Apr 2011 12:06:29 -0000 Received: (qmail 10868 invoked by uid 22791); 25 Apr 2011 12:06:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Apr 2011 12:06:13 +0000 Received: (qmail 22195 invoked from network); 25 Apr 2011 12:06:12 -0000 Received: from unknown (HELO ?172.16.1.234?) (maxim@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Apr 2011 12:06:12 -0000 Subject: Re: [PATCH] Improve combining of conditionals Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-4--991545456 From: Maxim Kuvyrkov In-Reply-To: <66F48FC0-456C-43A3-878E-0868BA3C96D2@codesourcery.com> Date: Mon, 25 Apr 2011 15:32:00 -0000 Cc: gcc-patches Message-Id: <1FC87A17-BFD1-4FA2-9309-AA9DE2670832@codesourcery.com> References: <33F4E740-6ED2-4694-B63C-E43ED3B91461@codesourcery.com> <201104151334.32639.ebotcazou@adacore.com> <66F48FC0-456C-43A3-878E-0868BA3C96D2@codesourcery.com> To: Eric Botcazou X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01965.txt.bz2 --Apple-Mail-4--991545456 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Content-length: 1251 On Apr 15, 2011, at 4:38 PM, Maxim Kuvyrkov wrote: > On Apr 15, 2011, at 3:34 PM, Eric Botcazou wrote: >=20 >>> The problem this patch fixes is that combine_simplify_rtx() prefers to >>> return an expression (say, ) even when a comparison is >>> prefered (say, ). Expressions are not recognized = as >>> valid conditions of if_then_else for most targets, so combiner misses a >>> potential optimization. This patch makes combine_simplify_rtx() aware = of >>> the context it was invoked in, and, when appropriate, does not discoura= ge >>> it from returning a conditional. >>=20 >> Btw, this is very likely also valid for targets with STORE_FLAG_VALUE = =3D=3D -1 so=20 >> the same IN_COND short-circuit would need to be added a few lines below = in=20 >> combine_simplify_rtx. But this would need to be tested. Do you happen = to=20 >> have access to such a target, e.g. m68k? >=20 > Hm, I didn't notice that one, thanks! I have access to m68k (ColdFire, t= bp) and will test this change there before committing. I've successfully tested the following trivial patch on m68k-linux (cross-c= ompiler, gcc, g++ and libstdc++ testsuites). Checked in as obvious. -- Maxim Kuvyrkov Mentor Graphics / CodeSourcery --Apple-Mail-4--991545456 Content-Disposition: attachment; filename=fsf-gcc-combine-fix-1.ChangeLog Content-Type: application/octet-stream; name="fsf-gcc-combine-fix-1.ChangeLog" Content-Transfer-Encoding: 7bit Content-length: 202 2011-04-25 Maxim Kuvyrkov Eric Botcazou * combine.c (combine_simplify_rtx): Avoid mis-simplifying conditionals for STORE_FLAG_VALUE==-1 case. --Apple-Mail-4--991545456 Content-Disposition: attachment; filename=fsf-gcc-combine-fix-1.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="fsf-gcc-combine-fix-1.patch" Content-Transfer-Encoding: 7bit Content-length: 525 Index: combine.c =================================================================== --- combine.c (revision 172929) +++ combine.c (working copy) @@ -5787,7 +5787,10 @@ combine_simplify_rtx (rtx x, enum machin /* If STORE_FLAG_VALUE is -1, we have cases similar to those above. */ - if (STORE_FLAG_VALUE == -1 + if (in_cond) + ; + + else if (STORE_FLAG_VALUE == -1 && new_code == NE && GET_MODE_CLASS (mode) == MODE_INT && op1 == const0_rtx && (num_sign_bit_copies (op0, mode) --Apple-Mail-4--991545456--