From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id A43D3385C6FC for ; Sat, 28 Oct 2023 20:29:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A43D3385C6FC Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A43D3385C6FC Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698524955; cv=none; b=m0nelVb1Mz63KPo8Wx+2+8kaGREMKTkqJWX7xjM0+Dp++tN/xbMvWkjbVkovfyPwt4aluaqg94vkgpY6A6FDacL8wtC2QRtRlmt5lurYZxQoteW+KIQB+3LhZ5v9XsSnMc2whu73PS4J9KGnY1Iey/2JueJsAruwSbfIeqRFlao= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698524955; c=relaxed/simple; bh=RngB14EeTDl4K8yLjDeeMKBRIimGL+6u9jEQw7BOW40=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=Hc2eWkU1T+sMavgpHakqDR6xexF2jXkSaL2EqcOEnqSkOz7OoULElpEaMgdEeCoG6xZqbzzaGH7OPPZwLHRug7vSVanzVrCMDyoAykjhfFNzvqUDZN1Oboql9LyVtUWQD9FupSpdQIStRIGaVgO1Gn1Nd0NQuC+7GUx8BW3n2wI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-169-114.tugraz.at (vra-169-114.tugraz.at [129.27.169.114]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SHrjD3K5yz1LM05; Sat, 28 Oct 2023 22:29:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4SHrjD3K5yz1LM05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1698524944; bh=NfX8y4vBi8RBPXdZPWFa+Jja2HgSDqBGhISvNtGRY+8=; h=Subject:From:To:Date:In-Reply-To:References:From; b=FFqiye7hc7iga8tuLvEqFe9oCREPPStwuXO2jCdr4E6puTmVDIJo4ffZZgREZHWUu +F+OP7G9Ete3UigW+z5sZkfK/V9mQklVaLVi7gXLWXL8uEPG82Gzi/BkbEgj80lKin X07gkGQcgp7Pf6XFQ2+sw9NKxeAGO/Kp12WAGb0M= Message-ID: <5a28c1c4d9a5c63d806f49198b5a8445537dab4d.camel@tugraz.at> Subject: Re: [PATCH] tree-optimization/109334: Improve computation for access attribute From: Martin Uecker To: Siddhesh Poyarekar , gcc-patches@gcc.gnu.org Date: Sat, 28 Oct 2023 22:29:03 +0200 In-Reply-To: <0ebb3b58-e6dc-4147-aa24-d12c1516756f@gotplt.org> References: <67644e18c4a0ba9febd1b0e82080f74e387b83f7.camel@tugraz.at> <0ebb3b58-e6dc-4147-aa24-d12c1516756f@gotplt.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Thanks, Sid! (one comment below) Am Donnerstag, dem 26.10.2023 um 07:51 -0400 schrieb Siddhesh Poyarekar: > On 2023-10-26 04:37, Martin Uecker wrote: >=20 > > /* ... and either PARM is void * or has a type that is complete= and has a > > constant size... */ > > && ((typesize && poly_int_tree_p (typesize)) > > @@ -1587,10 +1587,14 @@ parm_object_size (struct object_size_info *osi,= tree var) > > unsigned argpos =3D 0; > > =20 > > /* ... then walk through the parameters to pick the size parame= ter and > > - safely scale it by the type size if needed. */ > > + safely scale it by the type size if needed. > > + > > + TODO: we could also compute the size of VLAs where the size is > > + given by a function parameter. */ >=20 > Isn't this testcase h() in builtin-dynamic-object-size-20.c? If you're= =20 > referring to testcase i(), then maybe "where the size is given by a=20 > non-trivial function of a function parameter, e.g. > fn (size_t n, char buf[dummy(n)])." h() is supported. For i() we would need something as __builtin_access__with_size to record the result of dummy(). But the comment refers to the simpler case: fn (size_t n, char (*buf)[n]) [[gnu::access(read_write, 2, 1)]] This doesn't work because buf[n] does not have constant size, but it could be made to work more easily because the size is directly given by a function argument. Martin >=20 > > for (arg =3D fnargs; arg; arg =3D TREE_CHAIN (arg), ++argpos) > > - if (argpos =3D=3D access->sizarg && INTEGRAL_TYPE_P (TREE_TYPE (arg))= ) > > + if (argpos =3D=3D access->sizarg) > > { > > + gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (arg))); > > sz =3D get_or_create_ssa_default_def (cfun, arg); > > if (sz !=3D NULL_TREE) > > { > >=20 >=20 > We rely on the frontend to make sure that the arg at sizarg is an=20 > integral type. OK. >=20 > Overall the change looks OK with a few nits I pointed out above. >=20 > Thanks, > Sid