From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12887 invoked by alias); 6 May 2014 12:16:59 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 12876 invoked by uid 89); 6 May 2014 12:16:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 May 2014 12:16:56 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s46CGtnG001288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 6 May 2014 08:16:55 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-142.phx2.redhat.com [10.3.113.142]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s46CGsFe029137; Tue, 6 May 2014 08:16:54 -0400 Message-ID: <5368D2B6.5000502@redhat.com> Date: Tue, 06 May 2014 12:16:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Florian Weimer , "gcc-help@gcc.gnu.org" Subject: Re: Target dependence of conditional expression gimplification References: <53146FAA.8090802@redhat.com> <5367A8BF.5010805@redhat.com> <5367B81F.9020401@redhat.com> <53689C53.2050603@redhat.com> In-Reply-To: <53689C53.2050603@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00022.txt.bz2 On 05/06/14 02:24, Florian Weimer wrote: > On 05/05/2014 06:11 PM, Jeff Law wrote: > >> Yes, this is a known issue. There's places where the costing models >> change the gimple we initially generate and what transformations we >> apply later. > > Well, "known issue" is very subjective. Our developers run into this > quite regularly because you get more -Wstrict-overflow warnings on ppc64 > and s390x than on x86_64. The GIMPLE on x86_64 contains fewer > conditional statements, so the warning does not fire. That unfortunately happens. We don't guarantee warning stability across platforms. > >> Long term we want to push this stuff to a later point in the pipeline, >> but there's some disagreement over exactly how/when to do that. > > Would it be feasible (for someone like me who is not really familiar > with GCC internals) to move the BRANCH_COST-dependent bits of fold to an > early GIMPLE pass? There's another target dependence related to > function pointers which could receive similar treatment. Moving the bits is easy. Verifying that doing so doesn't hurt performance is the real work here. And in the process of looking at the performance side, you're going to run into a rats nest of issues. If it were easy, it'd already have been done. Jeff