From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id B17963858C52 for ; Fri, 20 Oct 2023 14:33:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B17963858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B17963858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697812434; cv=none; b=wMelMcvQ8wqlmlW6Qhzv7BKYVPC6OFl+ZyIxOxhNdV2fAD5pRB0JMxYVpC/tMBqu5gJZdfYYG2YpMguuI0c/WXlGXsBiswnzIiluM8ZWqOntXZBE8Lvb9fpzLvpql/pmju/AC+7BBta5I1M6HIqXJF3XG2+QNYdWuDZ7J4FQU34= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697812434; c=relaxed/simple; bh=yB2n+cTabPVm2aGv4qbsvxin8mSk3UsIjzEw5amKp4Q=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=xBUXLABwYvQ67Az90Xnbfo3GbKggq3tIJ0UEZ/XH/ykyRAFEohxNrX2KZ+oCatDSkEutSVAQ7TfpeoxD+5bj8gIL8OqSrJe1rB9672BJ1QTwup+J+JsHUhtllE94K4TdSn1PJ2Xtd2D3pGbrqZmug2O5OwpiCSpIO2bAk5Fe46A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-507be298d2aso1257249e87.1 for ; Fri, 20 Oct 2023 07:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697812431; x=1698417231; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H25J4EDqIFYJwabUuZ/S3XTNk1BoMHhWZUGbdpi3EIA=; b=fUZOHo1rd/MtJdRyjYFh77vl5Vf1CTUMuAiURupUK6AQAJ1UsuXvxKIdCL4UODXbu9 DqfKYN7ZhmnHuSM/Z9DkzDsDwgK/JBed+6brVWMP7UvvGk1dtHEhB3NOSfMDapNvwYJ6 h7XXRBa9VPST9ytVZ9lBl34aP027TTN+UgyBB5zDJhxZ2BsGUHWf1n3ZG25tma8ghH5O AvR4kzZJdEsLwKvk+dWZh2OY4p0a2CQfo+m5SdtPogEw7N/2IU8mBAve6NXQFyaXQTb4 E0cWIWG3uogCmwA8lCUcZH5PYyJMtR0U42HDe5byXl35GTk849+3sVKafnidklqH+G+G ZTyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697812431; x=1698417231; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H25J4EDqIFYJwabUuZ/S3XTNk1BoMHhWZUGbdpi3EIA=; b=iwQRseNAm7oSbFSZ+tyUPg4A6Jqz+X/u52pKn9tyquLSITb1CqOV/2owFjVNez1cfr h8PoXfAdCainka74T6rXqunyIbx0CSq+U1ivItEqzY5TKKKqYxGKfNVg/XgX5bHUEeSm EkMdNhe2s0aktcrSHUNPY0AvVv1hxQjqU/xBKVU3ZiZU7lcTj0QJ7hHzaKjnFVXdaDZR liD00tt/S/zOUNsq6wl13Ta19sNePGFuDOZW+Znt2aNDU/AbkfCj5IkN0P9SOQ6UVkIS 1VThZSBBVWCA4X9jWiAcZOttJSV55ev1a4Ib9U3U/qgKksDpCRtAtTHlX9rdyn8cQqgi eK2A== X-Gm-Message-State: AOJu0YxbTmibfokAOt3hfSc5/kSMCA9mPiLbxWrowVQuKSpO6Pzqk+nq Y5UIBSxQ1/dAbeiwVw+y0tb6X0LlPKkZXymdIuQ= X-Google-Smtp-Source: AGHT+IFQ9aIcH3q+vgc7olZXtd872rZuUWZIeZwcp4nYVeOKTaK/fVtPPigQx+3WRhuEr4D7XGlCa5Fn0gl/ovhd660= X-Received: by 2002:a05:6512:6c4:b0:503:2555:d1e7 with SMTP id u4-20020a05651206c400b005032555d1e7mr1727000lff.45.1697812430848; Fri, 20 Oct 2023 07:33:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hanke Zhang Date: Fri, 20 Oct 2023 22:33:39 +0800 Message-ID: Subject: Re: Question about the pass_fre about merging if blocks. To: Richard Biener Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Biener =E4=BA=8E2023=E5=B9=B410=E6=9C= =8820=E6=97=A5=E5=91=A8=E4=BA=94 21:33=E5=86=99=E9=81=93=EF=BC=9A > > On Fri, Oct 20, 2023 at 1:48=E2=80=AFPM Hanke Zhang via Gcc wrote: > > > > Hi, I'm trying to make pass_fre work better for me. But I got a > > problem. Like the code below: > > > > int glob; > > > > void __attribute__((oninline)) > > foo() { > > // do nothing meaningful > > } > > > > int main() { > > if (glob) { > > foo(); > > } else { > > // do something that won't change glob > > } > > > > if (glob) { > > foo(); > > } else { > > // do something that won't change glob > > } > > } > > > > I'm trying to merge the two if blocks. And of course it won't work. I > > see the code in tree-ssa-structalias.cc, it will do this check: > > > > static bool > > pt_solution_includes_1 (struct pt_solution *pt, const_tree decl) { > > // xxxx > > if (pt->nonlocal > > && is_global_var (decl)) > > return true; > > // xxxx > > } > > > > So the pt->nonlocal will prevent the merge. I would like to ask if I > > can make this check less rigid by providing more information about > > function foo(). Because obviously the foo function does not change the > > value of glob here, but it is caused by the fact that it is noinline. > > > > So if I can prove that foo won't change glob and pass this infomation > > to this check, my goal was achieved. Is this possible? > > In case 'glob' were static IPA reference has this info and we'd already > use it from call_may_clobber_ref_p. There's IPA mod-ref which is > a bit more powerful than IPA reference but I think it does not record > this precise info. > > Note that the problem with non-static globals is that we do not know > whether they get modified indirectly because they might have their > address take in another TU and that address passed back into the TU. > Usually using LTO helps here and we can promote the decl to hidden > visibility. Hi Richard: Thanks for your replying. Yeah, I know that. (We do not know whether they get modified indirectly because they might have their address take in another TU and that address passed back into the TU.) But I think in my case, I think I have to let go of some security concerns. And LTO is enabled already in my case, but that doesn't help. So I can understand that the information includes whether Foo uses glob directly is actually used, but for security reasons, GCC does not use it as a basis here (pt_solution_includes_1). Right? So if I want to change the default behavior of GCC, can I use call_may_clobber_ref_p to check out and make it merge here? Thanks Hanke Zhang > > Richard. > > > > > Thanks > > Hanke Zhang