From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 76E7B3858D20 for ; Fri, 20 Oct 2023 15:27:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 76E7B3858D20 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 76E7B3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::531 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697815625; cv=none; b=nhMN9HY8d7ZlqR0EV5qvfuNb6xBcxvdEyINnn57vUWsCMLJgC5dVPvp5lGhavvWCn39UwncTQ7JvtW/A06PIJHHnmsNhCCGy2iawMHECrceydaCn9VavYHTTCH2oy6cyEeTx1k1iQ7LrM7s/cmtJrF3C2wg+HbwDvhp72v+9wGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697815625; c=relaxed/simple; bh=YThkDuM2NltxXiMIHgq1TXbzyy6m9hNwB+tULTmkD/4=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=xY0Ue+wK/LpbPwRZwLl1i0BmPOfT2UtiaTPYPKLFPoOWic6Y7GvujZx4HYdhAvGLftlfzbckvpJp5W9blt/xyY+m3o6NYLxqJ0oU3r1lEAwdhejlm4HvJsgZ+6e2y+Q5V1GDVYOZF5qawjQPVYv6qD3GLP0368M6EG85IXVlvKo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-53db1fbee70so1375018a12.2 for ; Fri, 20 Oct 2023 08:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697815622; x=1698420422; darn=gcc.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=w2clv9chPPC9VTuuDOKGQNAmaY5Rj0F+9ygEDBy8zjA=; b=VpvaYpdw7ZYafy8ZpjaZWiXO0GxjY3rb6nqixbgeD5ksfUnuGQottqeI4i9huzQN+2 oJmqJkZFOI71DNU/5Qpcb6A4u7o9gZF9bxjw3PY8pqeiT6j96MOCiR/nB0Anz4WngnCy DFbI7CrGGsQA81zsJ8Q7Gl4mrb85meBqikLwjFlW8tkRL13K1HjHZbvCJ5XZQcQfJLIg VkimB0POYCGLWUBwz110UBELAnU5yGFIAFDRG/pD+FBYaFgmOfmS2HG/bQdtvewJuBAU 06jVZAWpkQuswiP+luBYhDKqyvhnWPRvPMYh9rUavzBxvO9jpoBXc9eVKbxDDTzkJdyH 7a3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697815622; x=1698420422; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w2clv9chPPC9VTuuDOKGQNAmaY5Rj0F+9ygEDBy8zjA=; b=Fyd0JAEPKJvn3Iqq2ovjFdhuJGD2cBRu4fj2/Bl5hEEnJZ1hzSuRZZj6c78xOI0LQ3 zxe17Xhi3IeuvQxm25CgPWDhOTENoKo2pQH2DD4A8SGiN8mA/oj8x68JPaCzkgXble2b au/4R5hFpAdZ1JJ8xVvHnMnjSFzqA97K75djx/WxAs7EnApEvGiqAy0oUxOT9xklACqr pRpctgaBBaDtzgG9hRrkpFwXn08aMbRECUQL7vsyoGXY+IW1zmhw82fxspxc9UAwsv8x 7lghUc0SfxvSt3o+xVtkPo0kohyA3zJrKjrXHsLI6K3rwYIc6CwszFAY7kKUSJ0wpGcD LSfQ== X-Gm-Message-State: AOJu0YyFHIO2x/oZMzr3zAc437ojsjErxP1HS/O5AA5tZyYmPlgZ6HYl T5NFncdFI0IaCAqTxM6VtrA= X-Google-Smtp-Source: AGHT+IFdMP3xv4xQeER5/DJ0TJSEHXoaBhxuljBN0qQjh49K1sEzB1qTeE2PVxX3MvgrH/3xpEbzaQ== X-Received: by 2002:a50:d09b:0:b0:53e:3b8f:8a5a with SMTP id v27-20020a50d09b000000b0053e3b8f8a5amr1539615edd.39.1697815621694; Fri, 20 Oct 2023 08:27:01 -0700 (PDT) Received: from smtpclient.apple (dynamic-095-117-050-188.95.117.pool.telefonica.de. [95.117.50.188]) by smtp.gmail.com with ESMTPSA id cf15-20020a0564020b8f00b0053deb97e8e6sm1609204edb.28.2023.10.20.08.26.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Oct 2023 08:26:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: Question about the pass_fre about merging if blocks. Date: Fri, 20 Oct 2023 17:26:35 +0200 Message-Id: <3D9E639F-E85D-4E56-89E3-09218896F001@gmail.com> References: Cc: gcc@gcc.gnu.org In-Reply-To: To: Hanke Zhang X-Mailer: iPhone Mail (20H30) X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Am 20.10.2023 um 16:33 schrieb Hanke Zhang : >=20 > =EF=BB=BFRichard Biener =E4=BA=8E2023=E5=B9=B4= 10=E6=9C=8820=E6=97=A5=E5=91=A8=E4=BA=94 21:33=E5=86=99=E9=81=93=EF=BC=9A >>=20 >>> On Fri, Oct 20, 2023 at 1:48=E2=80=AFPM Hanke Zhang via Gcc wrote: >>>=20 >>> Hi, I'm trying to make pass_fre work better for me. But I got a >>> problem. Like the code below: >>>=20 >>> int glob; >>>=20 >>> void __attribute__((oninline)) >>> foo() { >>> // do nothing meaningful >>> } >>>=20 >>> int main() { >>> if (glob) { >>> foo(); >>> } else { >>> // do something that won't change glob >>> } >>>=20 >>> if (glob) { >>> foo(); >>> } else { >>> // do something that won't change glob >>> } >>> } >>>=20 >>> 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: >>>=20 >>> static bool >>> pt_solution_includes_1 (struct pt_solution *pt, const_tree decl) { >>> // xxxx >>> if (pt->nonlocal >>> && is_global_var (decl)) >>> return true; >>> // xxxx >>> } >>>=20 >>> 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. >>>=20 >>> 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? >>=20 >> 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. >>=20 >> 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. >=20 > Hi Richard: >=20 > Thanks for your replying. >=20 > 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.) >=20 > 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. It=E2=80=99s not security it=E2=80=99s correctness. >=20 > 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? I don=E2=80=99t think this function is the correct place for the fix. I=E2=80= =99d instead put it into =E2=80=A6 > So if I want to change the default behavior of GCC, can I use > call_may_clobber_ref_p to check out and =E2=80=A6 this function where it would be more targeted. As said, you are going to miscompile valid code. Note it should be possible= to enhance IPA reference dependent on how foo actually looks like (like if t= here are no pointer based accesses in it). Richard. > make it merge here? >=20 > Thanks > Hanke Zhang >=20 >>=20 >> Richard. >>=20 >>>=20 >>> Thanks >>> Hanke Zhang