From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94658 invoked by alias); 30 Jul 2019 08:44:43 -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 94450 invoked by uid 89); 30 Jul 2019 08:44:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=records X-HELO: mail-lf1-f66.google.com Received: from mail-lf1-f66.google.com (HELO mail-lf1-f66.google.com) (209.85.167.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Jul 2019 08:44:40 +0000 Received: by mail-lf1-f66.google.com with SMTP id r15so27132767lfm.11 for ; Tue, 30 Jul 2019 01:44:39 -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=DdEy419b9RzViwDZ14ksXs+TYJN1O09mVUgcGwaxtj8=; b=AI2z/V2T+bR3quGyX/NrCTHNhsd5O7S17Qezhvhz3gwwuuctm5k6GO9cdupgj0Yq7b 622woinEM6DUcVvpB6Sv/uyHAXGgbLbMvTc3aGx1HztxFBs8vRT3qIMZvK9OTzNkrTiY rNuJr1apEu2HLLFgkj4adYKbmiNqlDhMl81XB24qkcM+J5khynxPBXDxR2YnkjZ97F4F 9BmKmlpHZ2U6zCpKHwc41nVXQydDoD1Ew8iIIQY4JGJTqdCQOQJ8xwH5FAJmGSnIbIO5 vEUfvK+arpnqAwHah7psl7eG+L70X7iLAGszh4igcWOeYvbYwA1V3X/MR5+STfkOr28Q Vfig== MIME-Version: 1.0 References: <187485ec-9c48-735e-54da-8b0820372fe2@redhat.com> <0f07b57e-9def-2758-c58b-ec9200fa4432@gmail.com> <20190729160348.GD15878@tucnak> <20190730083458.GN15878@tucnak> In-Reply-To: <20190730083458.GN15878@tucnak> From: Richard Biener Date: Tue, 30 Jul 2019 08:49:00 -0000 Message-ID: Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization To: Jakub Jelinek Cc: Martin Sebor , Jeff Law , JiangNing OS , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01772.txt.bz2 On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek wrote: > > On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote: > > Would you need to LTO stream & merge the bitmaps / maps somehow? > > Yes. And if we do not throw unneeded warnings from the sets normally, LTO > streaming might be a good time to do that, so that we merge in only warnings > that will be tested during/post IPA. > > > (maybe "unmap" to sth else when streaming individual stmts) Not sure if > > a bitmap is really necessary, we could simply have a tree/gimple * -> vec<> > > mapping with records about emitted (or queued) diagnostics, like > > OPT_, message pairs or so. > > Right now we use it both for the case we've already emitted some diagnostics > and don't want to emit it again later, or for the case where we insert > something in the IL that a warning could be diagnosed on but we know we > don't want that. The latter is the case e.g. for when we add > TREE_NO_WARNING on the last value in a statement expression so that we don't > diagnose it as unused, or the case we are discussing here. > If we need queued diagnostics, sure, we could add it in, but I don't see a > need for that right now. vecs compared to bitmap might be larger and harder > to avoid duplicates. I guess we'd need to do some analysis though, and e.g. > if 99% of cases we need to disable just one warning and not multiple, > perhaps optimize for that case. I was thinking we may want to use the same facility to record warnings we want to not emit if we later figure a stmt was in an unreachable region. For this we need to record the actual warning, not only the warning kind. Richard. > > Jakub