From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id B0F4A3858D20 for ; Mon, 15 Jan 2024 09:36:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0F4A3858D20 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 B0F4A3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705311413; cv=none; b=vJ8hcnYC90O6qmx0ZyaK5ujqm9MdUaz5ODmb/TXzMkbrU0K6VGNQFXut7yu2ZXv19PrYJCln5DnYW+8y0M2uqgjpum46R7N70VLRKAxXFXBKik3VnFzRQeC59tNfjjV/e7ptCVy4MeHhbXTVmGpYDk7K5Vs6eaRJfKS4hieoj2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705311413; c=relaxed/simple; bh=qftY8RadqKOf3eBmdDRo3v/qhF9EgLPSQncJSJ2MhrM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Xi7PysxXoVGvLdmf1Fmaz+oLGPHomDFrO7LZIcpwVsyN/SCjd2Oq9VzPDzT/DDTxxqPm7SE0T7KZ70iY1XtXslRWY0I3TmUfKHmyggsLTHL8mgZf39NxyAfGUtF61Lqu2+tLthWg7CDhNhavAVvBNqpjHiIbILEYeDV+hi69qhU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cdc1af60b2so8359371fa.1 for ; Mon, 15 Jan 2024 01:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705311407; x=1705916207; 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=baAMAjpm0Cr69HN5/SghCIV2P1ly6Y0nQfvX9kKB3Tg=; b=Cr8J8k9Vtve4Wk8tLKKZui3A7AmBRvvv4oyVZUiSFNQ4y371EJ7SEGHZWACI2Y/ADT vuiUoAHzqRNjkj/+hU2xj8tLKDgNwIPQwTCdEthe1PkKvFlmuxBDzhzEEKOW26Of8XCf 6WJmv7zDE+3AvHs2Lrchyp118fuAPME/kEObOEPmsE7Vg/uMhRKmhLJo0nr9qE+v6EO6 GV2dCCus6HDuv9Gx3EzxACpHq1KEl9jM3FrL3M0odJSxGOJrZCLMTb/tfksskvBoYYco K3sQCwNiCTG99ORUAvmYvOx6+ko5BWDHdlbpWTfcvY+V/vxdsCzSad5cL6Z0fiEQercj 47xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705311407; x=1705916207; 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=baAMAjpm0Cr69HN5/SghCIV2P1ly6Y0nQfvX9kKB3Tg=; b=qGi26LjeY8H6Ha8Arq/wuWxOsuRYzuUd08gLS2tbbtV8DQE6WOVfwppI96JYLZ9s2Q jo6NgDfniv5ZI0Z4kiqFTvb/H8rNxkqR5LQuCG5bOxi1RiKdw7CtBEKiiwn8BXHjBICT jOrlVmTgiv3oDg2j76WN1ZtkCsk+6PK1Y2TEB49yqqYTHLTbqRfweV9k0KiQA3k2qBLZ VH8ShaoFHp/029RKmeRVKIxzj5aFq0BDYXoPcG9gplEVg8Qewggj+sO2BkdkLsXnTGjt nKtyFyMqYoxvgFE+4zDCRuExk6HwZg+kfBbiZ8Ghu+4pmuurJyNWl+Y4y/0ndEwr9p1i zHGA== X-Gm-Message-State: AOJu0Yzg8gzpx/HMI3btLqY8lxeEAmaGxQi/VaA8hgwyazvmljkcmE6a E3D6QcYCK3MZul5p0uXlTOBCSGGnFb+/yZtXmvk= X-Google-Smtp-Source: AGHT+IER7ixfi9xgxv5aeB52sNWWjH+1zpbWw20lQGTa/tEdGxWXkN9xy7UUkWiSc9vHGRyzfL1ns6MK9vh/+IU+lgI= X-Received: by 2002:a2e:390a:0:b0:2cc:ea0d:f6c0 with SMTP id g10-20020a2e390a000000b002ccea0df6c0mr2285642lja.83.1705311406869; Mon, 15 Jan 2024 01:36:46 -0800 (PST) MIME-Version: 1.0 References: <50C8811D-9C2A-4FFB-9FC5-D24C5A76F868@oracle.com> <70C34042-B741-4697-9524-396CB9D40DF8@gmail.com> In-Reply-To: From: Richard Biener Date: Mon, 15 Jan 2024 10:31:28 +0100 Message-ID: Subject: Re: HELP: Questions on unshare_expr To: Qing Zhao Cc: gcc Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 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,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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: On Fri, Jan 12, 2024 at 6:30=E2=80=AFPM Qing Zhao wr= ote: > > Thanks a lot for the reply. > > > On Jan 12, 2024, at 11:28 AM, Richard Biener wrote: > > > > > > > >> Am 12.01.2024 um 16:55 schrieb Qing Zhao : > >> > >> =EF=BB=BFHi, > >> > >> I have some questions on using the utility routine =E2=80=9Cunshare_ex= pr=E2=80=9D: > >> > >> From my understanding, there should be NO shared nodes in a GENERIC fu= nction. > >> Otherwise, gimplication might fail. > > > > There is sharing and this is why we unshare everything before gimplific= ation. > > Okay, so, the "unsharing everything=E2=80=9D is done automatically by the= compiler before gimplification? > I don=E2=80=99t need to worry about this? > > I see many places in FE where =E2=80=9Cunshare_expr=E2=80=9D is used, fo= r example, =E2=80=9Cubsan_instrument_division=E2=80=9D, > =E2=80=9Cubsan_instrument_shift=E2=80=9D, etc. It's likely doing sth during gimplification. > So, usually, when should =E2=80=9Cunshare_expr=E2=80=9D be used? You should usually unshare when you are putting the same 'tree' into multip= le operands. Using a SAVE_EXPR avoids redundant code but it also requires that the SAVE_EXPR uses are ordered. > >> Therefore, when we insert new tree nodes manually into the GENERIC fun= ction, we should > >> Make sure there is no shared nodes introduced. > >> > >> 1. Is the above understanding correct? > > > > No > > > >> 2. Is there any tool to check there is no shared nodes in the GENERIC = function? > >> 3. Are there any tree nodes that are allowed to be shared in a GENERIC= function? If so, what are they? > > > > There=E2=80=99s some allowed sharing on GIMPLE and a verifier. > What=E2=80=99s the name of the verifier that I can search and check? verify_node_sharing > > > >> 4. For the following: > >> > >> If both =E2=80=9Cop1=E2=80=9D and =E2=80=9Cop2=E2=80=9D are existing t= ree nodes in the current GENERIC function, > >> and we will insert a new tree node: > >> > >> tree new_tree =3D build2 (CODE, TYPE, op1, op2) > >> > >> > >> Should we add =E2=80=9Cunshare_expr=E2=80=9D on both =E2=80=9Cop1=E2= =80=9D and =E2=80=9Cop2=E2=80=9D as: > >> > >> Tree new_tree =3D build2 (CODE, TYPE, unshare_expr (op1), unshare_expr= (op2)) > >> ? > > > > Not necessarily but instead you have to watch for evaluating side-effec= ts only once. See save_expr. > > Okay. I see. > > > >> > >> If op2 is a node that is allowed to be shared, whether the additional = =E2=80=9Cunshare_expr=E2=80=9D on it trigger any potential problem? > > > > If you unshare side-effects that=E2=80=99s generating wrong-code. Othe= rwise unsharing is safe. > > Okay. > Will unnecessary unshareing produce redundant IRs? Yes. > All my questions for unshare_expr relate to a LTO bug that I currently s= tuck with > when using .ACCESS_WITH_SIZE in bound sanitizer (only with -flto, without= -flto, no issue): > > [opc@qinzhao-aarch64-ol8 gcc]$ sh t > during IPA pass: modref > t.c:20:1: internal compiler error: tree code =E2=80=98ssa_name=E2=80=99 i= s not supported in LTO streams > 0x14c3993 lto_write_tree > ../../latest-gcc-write/gcc/lto-streamer-out.cc:561 > 0x14c3aeb lto_output_tree_1 > > And the value of the tree node that triggered the ICE is: > (gdb) call debug_tree(expr) > > nothrow > def_stmt > version:13 in-free-list> > > Is there any good way to debug LTO bug? This happens usually when you have a VLA type and its type fields are not properly gimplified which usually happens because the frontend fails to insert a gimplification point for it (a DECL_EXPR). > Thanks a lot for the help. > > Qing > > > > > > Richard > > > >> Thanks a lot for your help. > >> > >> Qing >