From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id D00923858C2F for ; Fri, 3 Nov 2023 00:28:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D00923858C2F 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 D00923858C2F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::22c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698971297; cv=none; b=WbrE7gSk4kDNdGnOyxFXMqlXTd2db8gKzbaoST5Zde4jWhOqWBinGGs1uIgQ1VfuNOYJFWHsaQxVyv+WL/k87zwjPI3m2Da+Kt6kllOBZi+JUlwippZH5sGblIsU7ay9Wy0EsURupkHHiQrkqqBx2wuCUs75u88GJQljth1e3hQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698971297; c=relaxed/simple; bh=Ylr+y86wioorQ42eBjSwIpEkPo5aLgm76Q2PupwmBOs=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Bo0RMkKgxlh989vcGZMcMZQvl7pBEuU8LeO64U4bStIWFvJOJ+/bn98mVrbh0rNn2RGkZZWcoANwCjmaN6y2zM91Ix+zPgAb9k35ZV9LlhbBHxpKavgg+O5Z/uSiKGhpRqbv1E4EyC+wJ2nHdM5w5ej6h6JCIfkTgbCbZpmIx9I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x22c.google.com with SMTP id 5614622812f47-3b2f2b9a176so975751b6e.0 for ; Thu, 02 Nov 2023 17:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698971295; x=1699576095; 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=UCRUM0ja4OGtDvaa4OK1WixwsyuMKNOVJ0MQYKrQ020=; b=AuKZAQ3KS3pSB2jt6G/mNPjeLRM8LWtfjPLn6ejnOvYBqvQjqvqpFzd5R5FFeeQ6es Qxv88VkXhtzlUQIqHp+sUbLKrR/UpaZMgW/nhzrlbkGvhCdKjB+O45JrFoe7VZIL15Td 06wX+FNKCjEtn0XVszK9M2nfdDp1HzimnjbeHpMDrXdwYCTIok+6chjaVa9o11P0U/2m CNJ4bemHW5Eqsy8Fy/Nah/StBIUnm7UPMyhvlm3rQoqiowjbRek4BzN0xqfv7SXM6+bK srOI9el76KkjI9WIq5JsmFm39zXPGwlN5sTIbDaIb4Cpkdc5NUynhMWLRB+RMpwQwnf5 yXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698971295; x=1699576095; 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=UCRUM0ja4OGtDvaa4OK1WixwsyuMKNOVJ0MQYKrQ020=; b=ppSsjpSHBPpNeVjCK5bkLU2pUNYWoJLXeUkU0KArnP0Yk3zEUVj+UMgM4muYESt3ld NKrRQCma7SrbGEfR4Lo9Y6ElPycRD344xOcUhq6BzWIqH+1rgbEtbsL0NStAJT5VIz3E LUFhRNvA5GjgaR8C5eB6jfKvwbrfvVqruBFcKr3kLseN0UI9tUKkUtTXsCKuaipnixQS AP0o2vLUUKbZOqkbO7eK0tr4CGk7+0dgbbdnsDkn9rICsU364Xla3y+A8MgirglyMGqb Wp+ImZ3BsKDawWAk5WTeTniwpRh6IfSDVJMLDi6GnEjoogAHIvHpBF3YTYnvTrrooixX jGHw== X-Gm-Message-State: AOJu0Ywiw7ntyVLQhNV7kiF9DiktR5b1crN4UNy2QvttZ4N+8yc7KN+u WFCqaoJvGAp8Uzm2dOL4Dvx72iRUctoP4ofWkTY= X-Google-Smtp-Source: AGHT+IEBk7X00PLbMG+gIOc+JaJa6vSGT9ufWVRe2rNWL+mx67i7thFy+2fxSuO1+4vErDDiAl4f8xXuhtn6tu1TPN8= X-Received: by 2002:a05:6870:9711:b0:1ef:d2b2:fe56 with SMTP id n17-20020a056870971100b001efd2b2fe56mr16228320oaq.0.1698971294718; Thu, 02 Nov 2023 17:28:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bill Wendling Date: Thu, 2 Nov 2023 17:28:03 -0700 Message-ID: Subject: Re: RFC: the proposal to resolve the missing dependency issue for counted_by attribute To: Qing Zhao Cc: Jakub Jelinek , Richard Biener , Kees Cook , Joseph Myers , Siddhesh Poyarekar , Martin Uecker , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.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 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 Thu, Nov 2, 2023 at 1:36=E2=80=AFPM Qing Zhao wro= te: > > Thanks a lot for raising these issues. > > If I understand correctly, the major question we need to answer is: > > For the following example: (Jakub mentioned this in an early message) > > 1 struct S { int a; char b __attribute__((counted_by (a))) []; }; > 2 struct S s; > 3 s.a =3D 5; > 4 char *p =3D &s.b[2]; > 5 int i1 =3D __builtin_dynamic_object_size (p, 0); > 6 s.a =3D 3; > 7 int i2 =3D __builtin_dynamic_object_size (p, 0); > > Should the 2nd __bdos call (line 7) get > A. the latest value of s.a (line 6) for it=E2=80=99s size? > Or B. the value when the s.b was referenced (line 3, line 4)? > I personally think it should be (A). The user is specifically indicating that the size has somehow changed, and the compiler should behave accordingly. > A should be more convenient for the user to use the dynamic array feature= . > With B, the user has to modify the source code (to add code to =E2=80=9Cr= e-obtain=E2=80=9D > the pointer after the size was adjusted at line 6) as mentioned by Richar= d. > > This depends on how we design the new internal function .ACCESS_WITH_SIZE > > 1. Size is passed by value to .ACCESS_WITH_SIZE as we currently designed. > > PTR =3D .ACCESS_WITH_SIZE (PTR, SIZE, ACCESS_MODE) > > 2. Size is passed by reference to .ACCESS_WITH_SIZE as Jakub suggested. > > PTR =3D .ACCESS_WITH_SIZE(PTR, &SIZE, TYPEOFSIZE, ACCESS_MODE) > > With 1, We can only provide B, the user needs to modify the source code t= o get the full feature of dynamic array; > With 2, We can provide A, the user will get full support to the dynamic = array without restrictions in the source code. > My understanding of ACCESS_WITH_SIZE is that it's there to add an explicit reference to SIZE so that the optimizers won't reorder the code incorrectly. If that's the case, then it should act as if ACCESS_WITH_SIZE wasn't even there (i.e. it's just a pointer dereference into the FAM). We get that with (2) it appears. It would be a major headache to make the user go throughout their code base to ensure that SIZE was either unmodified, or if it was that extra code must be added to ensure the expected behavior. > However, We have to pay additional cost for supporting A by using 2, whic= h includes: > > 1. .ACCESS_WITH_SIZE will become an escape point, which will further impa= ct the IPA optimizations, more runtime overhead. > Then .ACCESS_WTH_SIZE will not be CONST, right? But it will still be = PURE? > > 2. __builtin_dynamic_object_size will NOT be LEAF anymore. This will als= o impact some IPA optimizations, more runtime overhead. > > I think the following are the factors that make the decision: > > 1. How big the performance impact? > 2. How important the dynamic array feature? Is adding some user restricti= ons as Richard mentioned feasible to support this feature? > > Maybe we can implement 1 first, if the full support to the dynamic array = is needed, we can add 2 then? > Or, we can implement both, and compare the performance difference, then d= ecide? > > Qing >