From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105583 invoked by alias); 26 Feb 2018 20:05:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 105568 invoked by uid 89); 26 Feb 2018 20:05:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=tension, HContent-Transfer-Encoding:8bit 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; Mon, 26 Feb 2018 20:05:01 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E58347FECA; Mon, 26 Feb 2018 20:04:59 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-67.rdu2.redhat.com [10.10.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 05FA9620A4; Mon, 26 Feb 2018 20:04:58 +0000 (UTC) Subject: Re: determining aggregate member from MEM_REF To: Martin Sebor , Richard Biener Cc: GCC Mailing List References: <108da35d-4146-2b3a-a667-692d41bcf8f6@gmail.com> <930e0618-0ea8-573d-8b51-beafa7969565@gmail.com> <73154b0a-a27e-78b9-ee71-f7f546c89421@gmail.com> From: Jeff Law Message-ID: <2d7a188f-e510-c884-958e-07e6e9e41528@redhat.com> Date: Mon, 26 Feb 2018 20:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <73154b0a-a27e-78b9-ee71-f7f546c89421@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00212.txt.bz2 On 02/26/2018 08:44 AM, Martin Sebor wrote: > > Folding things to MEM_REF (or rather, folding them too early) > makes all kinds of analysis harder: not just warnings but even > optimization.  I've raised a whole slew of bugs for the strlen > pass alone where folding string functions to MEM_REF defeats > useful downstream optimizations.  Making strlen (and all other > passes that might benefit from the original detail) work hard > to deal with MEM_REF isn't a good design solution.  It forces > the complexity that MEM_REF is meant to remove back into its > clients.  Worse, because of the loss of detail, the results > are unavoidably suboptimal (at least for certain kinds of > analyses). I haven't looked specifically at the MEM_REF folding, but I wouldn't be surprised to find cases where deferral ultimately results in regressions. When to fold & lower is a hard problem. There is a constant tension between trying to fold early as it often leads to generally better code vs folding later which may help other sets of code, particularly when folding results in an inability to recover data. There generally is not an optimal solution to these problems; we have to take a pragmatic approach. So if you can defer and not regress, then by all means propose patches. But I think you'll find that to defer means you have to beef up stuff later in the pipeline. jeff