From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id B14B0385B831 for ; Sun, 5 Apr 2020 18:48:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B14B0385B831 Received: by mail-wr1-x42c.google.com with SMTP id a25so14830536wrd.0 for ; Sun, 05 Apr 2020 11:48:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=7Vz/TYGBsw50xVzdt6fXc3szuI7XFExByIVjXqFNSwg=; b=SWlN6gXG6J3oKqVsPremjR0qqF5vWG93Df4uZvbdn9IXJSkIDQbM72tmn3OL1P48ZE b6BEo6u7kFgtE9ibGZTXUn2UdjJJ7Vx/SqAmD+kz5frvg7iVabiJNkUSnTaPQQtpuBCA xdJl1gA8ycpv3nccyoJO5VaVSXG2mxpJZvx/ufWTYOz4Bj190yerm8seNf57sR7hFwFC ObPbF+GzrPYQXcWHCMgTX/8ClGaRARn7fZ0JC5O1+Yp4pjXLpdfTUA2YaP2wpW5VIrGt JDTwDJfHAPzVk0zbS/pTplr5P3NIo/w1v5cx/1uJ8Mlj8RVonvOEsjoTbXuinVwyCzTC mBxQ== X-Gm-Message-State: AGi0PuY+7LsMnlczqPzBsj4l4ujxw0hKe7/Nqb/P1hr7psMy8vBjLlM1 XGvrRcbWq/QfvwdNXH6h0Vc= X-Google-Smtp-Source: APiQypL/2+c3sOeKG7sWGuRhLEaEVBLZRZpR6iXN+7PfJB4dvOYhTXb23Pp4C8u8UG2NGcc639TKQg== X-Received: by 2002:adf:afc3:: with SMTP id y3mr19017822wrd.144.1586112514757; Sun, 05 Apr 2020 11:48:34 -0700 (PDT) Received: from [192.168.178.32] (x4d07744b.dyn.telefonica.de. [77.7.116.75]) by smtp.gmail.com with ESMTPSA id f141sm21763197wmf.3.2020.04.05.11.48.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 11:48:34 -0700 (PDT) Date: Sun, 05 Apr 2020 20:48:31 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs To: law@redhat.com, Jeff Law via Gcc-patches , gcc-patches List CC: Ebotcazou@adacore.com From: Richard Biener Message-ID: X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 18:48:37 -0000 On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches wrote: > >So here's an approach to try and address PR80635=2E > >In this BZ we're getting a false positive uninitialized warning using >std::optional=2E > >As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR=20 >which isn't >handled terribly well by the various optimizers/analysis passes=2E > >We have these key blocks: > >;; basic block 5, loop depth 0 >;; pred: 3 >;; 2 > # maybe_a$m_6 =3D PHI <_5(3), maybe_a$m_4(D)(2)> > # maybe_a$4_7 =3D PHI <1(3), 0(2)> >: > _8 =3D maybe_b=2Elive; > if (_8 !=3D 0) > goto ; [0=2E00%] > else > goto ; [0=2E00%] >;; succ: 6 >;; 7 > >;; basic block 6, loop depth 0 >;; pred: 5 > B::~B (&maybe_b=2ED=2E2512=2Em_item); >;; succ: 7 > >;; basic block 7, loop depth 0 >;; pred: 5 >;; 6 > maybe_b =3D{v} {CLOBBER}; > resx 3 >;; succ: 8 > >;; basic block 8, loop depth 0 >;; pred: 7 >: > _9 =3D VIEW_CONVERT_EXPR(maybe_a$4_7); > if (_9 !=3D 0) > goto ; [0=2E00%] > else > goto ; [0=2E00%] >;; succ: 9 >;; 10 > >Where there is a use of maybe_a$m_6 in block #9=2E > >Of course maybe_a$m_6 only takes the value of maybe_a$m_4(D) when we >traverse the >edge 2->5 but in that case maybe_a$4_7 will always have the value zero >and thus >we can not reach bb #9=2E=2E But the V_C_E gets in the way of the analys= is >and we >issue the false positive warning=2E Martin Jambor has indicated that he >doesn't >see a way to avoid the V_C_E from SRA without reintroducing PR52244=2E > >This patch optimizes the V_C_E into a NOP_EXPR by verifying that the >V_C_E folds >to a constant value for the min & max values of the range of the input >operand >and the result of folding is equal to the original input=2E We do some >additional >checking beyond just that original value and converted value are equal >according >to operand_equal_p=2E > >Eventually the NOP_EXPR also gets removed as well and the conditional >in bb8 >tests maybe_a$4_7 against 0 directly=2E > >That in turn allows the uninit analysis to determine the use of >maybe_a$_m_6 in >block #9 is properly guarded and the false positive is avoided=2E > >The optimization of a V_C_E into a NOP_EXPR via this patch occurs a >couple >hundred times during a bootstrap, so this isn't a horribly narrow >change just to >fix a false positive warning=2E > >Bootstrapped and regression tested on x86_64=2E I've also put it through >its paces >in the tester=2E The tester's current failures (aarch64, mips, h8) are >unrelated >to this patch=2E > > >Thoughts? OK for the trunk? Alternately I wouldn't lose sleep moving >this to >gcc-11=2E ISTR Ada uses V_C_E to implement checks on value ranges to types=2E We nee= d to make sure to not interfere with this=2E=20 Richard=2E=20 > >jeff