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 7BBA63858C2D for ; Mon, 23 Oct 2023 15:58:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7BBA63858C2D 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 7BBA63858C2D 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=1698076682; cv=none; b=DS22LItfb31HuI6AZsXvBWit0V7ltgQmK04b3+Vobs+kKJxGTSlxdF0EYzFVBlstym8XGo0tOyYJ2vixxRBY61cAzrhNukds3UHxN03Z7N1y/dCOlx9rss22I5ZqEuyglVnfJuFmls4sQjLDjqDz9lyuD57ogTBiyQVop5LtXZE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698076682; c=relaxed/simple; bh=UWFlh7I2R66NPazMOvuNXyoedUIO08ufc2WYN6mAbt8=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=CCGxIIVFLjPWwXmXqv8XdvoRpn4hrgiY61smxggZVzdYjUoiZgH6GnYciOAOll6A9TfNUw4//Uj2ZZT42llmJ4AqCQ+UAD5wzW/XI3eOtuCHSGNq3IgeByL4D5xmbwKd/Hyenr3fEiBPPBPqQyzMlPunInoexxT92vQpA83BgRU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5079f3f3d7aso5466173e87.1 for ; Mon, 23 Oct 2023 08:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698076679; x=1698681479; 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=84n2yTEM6sWUSuRY5fM/CuFWo6Gg1Qm/SO7iZegWRg4=; b=Tp1x+kptnHTFarj+q9heRA6AMki5fbvKjxHvmkSZQAAHswAaN2RWMu4nwTUyEiZKHz w2DEYhB3p+9qNEzXOjtWOKs7PXfzn7f42NyD7jymU8Ty/ijUQo4A8DIKOFP4Usb698CM fJ+63TPMfma9qjRy6FH5XWekz9o1klqSi+YJMpwIld3DffPuYbLySuUkBCb38YM9yOJY 4yIkl4DJDMgEk9wDCi4P52opOPbukyN0mrh41O2W+/k7jMB6/led81BP9ZB9d76mHbgr QEtr3vAdImimhgmXESHQfHIZgq+9BGek7aWY60HR8WlkWC4chveoA1unqVIAVGzvf+lL eqOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698076679; x=1698681479; 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=84n2yTEM6sWUSuRY5fM/CuFWo6Gg1Qm/SO7iZegWRg4=; b=tVPTP/iuW5kbwMhK85X5U4Oy3+SLPRq2D6GNLno+AS8gXiq8B5L0r8N2RpwrAheXrA Pc7tR47WA9SEyHYFbw1TQSXpp9W0sHX2ugJPIGTDpCSaXkOk1vfouRQiMOd8jz3jKNCn Ra3gi4l/OisCHkBnaGzqi7xTh988Cjrg+/HaGxflesC58wIH+imDABj24gjcpQvAyD0D n1EGdV7DuXhSuBSfIeT4eTh5I6j26mPMQv4fKhIINv3PdnkuLwC71Hq9PZQKyN+hVTBG JtP8KpAjlLNK2JYa/SmjpDcm84NYwtlK3Z2dI8hpnqL95ycFylYW4c639SSVHmyTR8XZ WnRQ== X-Gm-Message-State: AOJu0YxW4HjkBg+YXw/QIEl4tYHAIle7n33x9VpfLdQtL5qhOJUmTZSs Vg3CPh4q4mLW2g7xkV16ClQ= X-Google-Smtp-Source: AGHT+IGGx3OJsJ7LpfSCdkGWbsF4eJxD1XP9exaGSN3Xcx5evyT/cCKbLRZ5QjAZKC6YjDrXlvLgZA== X-Received: by 2002:a05:6512:2399:b0:503:3913:c2c9 with SMTP id c25-20020a056512239900b005033913c2c9mr8894875lfv.40.1698076678518; Mon, 23 Oct 2023 08:57:58 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-009-115-084.77.9.pool.telefonica.de. [77.9.115.84]) by smtp.gmail.com with ESMTPSA id bd9-20020a056402206900b0053dab756073sm6480077edb.84.2023.10.23.08.57.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Oct 2023 08:57:57 -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: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) Date: Mon, 23 Oct 2023 17:57:47 +0200 Message-Id: References: <9DDD0677-BFE7-4733-8C11-0FA8B3C25569@oracle.com> Cc: Siddhesh Poyarekar , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , Martin Uecker , isanbard@gmail.com In-Reply-To: <9DDD0677-BFE7-4733-8C11-0FA8B3C25569@oracle.com> To: Qing Zhao X-Mailer: iPhone Mail (20H30) X-Spam-Status: No, score=-3.1 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 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 23.10.2023 um 16:56 schrieb Qing Zhao : >=20 > =EF=BB=BF >=20 >> On Oct 23, 2023, at 3:57 AM, Richard Biener w= rote: >>=20 >>> On Fri, Oct 20, 2023 at 10:41=E2=80=AFPM Qing Zhao wrote: >>>=20 >>>=20 >>>=20 >>>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar w= rote: >>>>=20 >>>> On 2023-10-20 14:38, Qing Zhao wrote: >>>>> How about the following: >>>>> Add one more parameter to __builtin_dynamic_object_size(), i.e >>>>> __builtin_dynamic_object_size (_1,1,array_annotated->foo)? >>>>> When we see the structure field has counted_by attribute. >>>>=20 >>>> Or maybe add a barrier preventing any assignments to array_annotated->f= oo from being reordered below the __bdos call? Basically an __asm__ with arr= ay_annotated->foo in the clobber list ought to do it I think. >>>=20 >>> Maybe just adding the array_annotated->foo to the use list of the call t= o __builtin_dynamic_object_size should be enough? >>>=20 >>> But I am not sure how to implement this in the TREE level, is there a US= E_LIST/CLOBBER_LIST for each call? Then I can just simply add the counted_b= y field =E2=80=9Carray_annotated->foo=E2=80=9D to the USE_LIST of the call t= o __bdos? >>>=20 >>> This might be the simplest solution? >>=20 >> If the dynamic object size is derived of a field then I think you need to= >> put the "load" of that memory location at the point (as argument) >> of the __bos call right at parsing time. I know that's awkward because >> you try to play tricks "discovering" that field only late, but that's not= >> going to work. >=20 > Is it better to do this at gimplification phase instead of FE?=20 >=20 > VLA decls are handled in gimplification phase, the size calculation and ca= ll to alloca are all generated during this phase. (gimplify_vla_decl). >=20 > For __bdos calls, we can add an additional argument if the object=E2=80=99= s first argument=E2=80=99s type include the counted_by attribute, i.e >=20 > ***During gimplification,=20 > For a call to __builtin_dynamic_object_size (ptr, type) > Check whether the type of ptr includes counted_by attribute, if so, change= the call to > __builtin_dynamic_object_size (ptr, type, counted_by field) >=20 > Then the correct data dependence should be represented well in the IR. >=20 > **During object size phase, >=20 > The call to __builtin_dynamic_object_size will become an expression includ= es the counted_by field or -1/0 when we cannot decide the size, the correct d= ata dependence will be kept even the call to __builtin_dynamic_object_size i= s gone.=20 But the whole point of the BOS pass is to derive information that is not ava= ilable at parsing time, and that=E2=80=99s the cases you are after. The cas= e where the connection to the field with the length is apparent during parsi= ng is easy - you simply insert a load of the value before the BOS call. For= the late case there=E2=80=99s no way to invent data flow dependence without= inadvertently pessimizing optimization. Richard=20 >=20 >>=20 >> A related issue is that assignment to the field and storage allocation >> are not tied together >=20 > Yes, this is different from VLA, in which, the size assignment and the sto= rage allocation are generated and tied together by the compiler. >=20 > For the flexible array member, the storage allocation and the size assignm= ent are all done by the user. So, We need to clarify such requirement in th= e document to guide user to write correct code. And also, we might need to p= rovide tools (warnings and sanitizer option) to help users to catch such cod= ing error. >=20 >> - if there's no use of the size data we might >> remove the store of it as dead. >=20 > Yes, when __bdos cannot decide the size, we need to remove the dead store t= o the field. > I guess that the compiler should be able to do this automatically? >=20 > thanks. >=20 > Qing >>=20 >> Of course I guess __bos then behaves like sizeof (). >>=20 >> Richard. >>=20 >>>=20 >>> Qing >>>=20 >>>>=20 >>>> It may not work for something like this though: >>>>=20 >>>> static size_t >>>> get_size_of (void *ptr) >>>> { >>>> return __bdos (ptr, 1); >>>> } >>>>=20 >>>> void >>>> foo (size_t sz) >>>> { >>>> array_annotated =3D __builtin_malloc (sz); >>>> array_annotated =3D sz; >>>>=20 >>>> ... >>>> __builtin_printf ("%zu\n", get_size_of (array_annotated->foo)); >>>> ... >>>> } >>>>=20 >>>> because the call to get_size_of () may not have been inlined that early= . >>>>=20 >>>> The more fool-proof alternative may be to put a compile time barrier ri= ght below the assignment to array_annotated->foo; I reckon you could do that= early in the front end by marking the size identifier and then tracking ass= ignments to that identifier. That may have a slight runtime performance ove= rhead since it may prevent even legitimate reordering. I can't think of ano= ther alternative at the moment... >>>>=20 >>>> Sid >=20