From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68333 invoked by alias); 26 Aug 2019 09:01:05 -0000 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 Received: (qmail 68322 invoked by uid 89); 26 Aug 2019 09:01:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lj1-f174.google.com Received: from mail-lj1-f174.google.com (HELO mail-lj1-f174.google.com) (209.85.208.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2019 09:01:04 +0000 Received: by mail-lj1-f174.google.com with SMTP id m24so14298546ljg.8 for ; Mon, 26 Aug 2019 02:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HeKtrQtnoKAZ+HceOQTxmoZDRmAd7T80hh9iswKxJNo=; b=tZ8NiQ5Sy/8d77BAeaon9KigQnbIm4QLxxfaS/hSlANGUudWHuZn9ZSq42P6fO0GMR WTjMM41a9wP7q4gQ0qbNWrJulmvJEUplFvdbGcuQFlwlsRTu/0KjjgIl5wtUX0kBG4n2 IlEAgzXYaWbABGot/Ov3zUiP8/fR53y8Ofdk6buqfCynvVv+2DL6IbGc6nqLgoO7+ja2 FwDdxF5HSgk8MsmDJmM26eyE0hOM2/ALHiSG7Rcha8Gnmas8EP1b2jxu7rV1JvQWpXbG RTukJmZPGiwCn/4BgLDpVekCoQFxowu4zfIEFL1fMQp09h7c8ODIMYubiJ2OolvT9SR2 G1fQ== MIME-Version: 1.0 References: <8b836cef-7aa1-fd3d-5585-c2a6fe74bed6@redhat.com> <72ac1813-0ca3-6798-a77b-7f1ab914d91c@redhat.com> In-Reply-To: From: Richard Biener Date: Mon, 26 Aug 2019 10:07:00 -0000 Message-ID: Subject: Re: [RFA] [tree-optimization/80576] Handle non-constant sizes in DSE To: Jeff Law Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg01731.txt.bz2 On Fri, Aug 23, 2019 at 9:19 PM Jeff Law wrote: > > On 8/22/19 4:46 AM, Richard Biener wrote: > >>> Also you seem to use this info to constrain optimization when you > >>> might remember that types of addresses do not carry such information... > >>> Thus it should be "trivially" possible to write a testcase that is miscompiled > >>> after your patch. I also don't see this really exercised in the > >>> testcases you add? > >> Arggh. You're absolutely correct. I must be blocking out that entire > >> discussion from last summer due to the trama :-) > >> > >> If the destination is the address of a _DECL node, can we use the size > >> of the _DECL? > > > > Yes, but this should already happen for both invariant ones like &a.b.c > > and variant ones like &a.b[i].c in ao_ref_init_from_ptr_and_size. > I don't see that in ao_ref_init_from_ptr_and_size. AFAICT if you don't > know the size when you call that routine (size == NULL), then you end up > with the ref->size and ref->max_size set to -1. > > Am I missing something here? Ah, of course. ao_ref_from_ptr_and_size would need to be extended to constrain max_size. So what I was saying is that ao_ref_init_from_ptr_and_size should get you a DECL ao_ref_base () from which you could constrain max_size with. Or rather ao_ref_from_ptr_and_size should be extended do that, mimicing what get_ref_base_and_extent does at the end in the if (DECL_P (exp)) case (mind flag_unconstrained_commons!). Richard. > > Jeff