From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 8BB8838515D9 for ; Wed, 7 Sep 2022 11:37:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BB8838515D9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=millistream.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=millistream.com Received: by mail-pf1-x434.google.com with SMTP id b144so9546994pfb.7 for ; Wed, 07 Sep 2022 04:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=millistream-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=i1ORoEDYoebRABVjBEb0KVzPBm7/AGh+IvnwqXoPf18=; b=UQGg/9Mr1bE3iLAwE3CzTUrPe69D2DCBhomrtyNS46repHnRGg/oXziB448jCPRhkG 4y3D31w8o6saj4OWx1i4dlNDrLt+MCdWRXM7b/NkQleRSIRLCCC64M0pzmdg7/aN8t/Z narR7wlhMFdjsfJXeMdFNYDeyAP22mNn7yWfi0Sh+VBx7DZvuGJ71UG6S/Ya0eLSTJR+ HfPaNyGLal3bKimK4fUBFAdpudi+4hxTjpYRVes0urBaxiTjPw7JapZ6qjlcw02vXd7w X0QVbQ0DdtpkGA3DaZqoG76qCHsQwbnUiMFJBXBq/FTqBhvaFOcI4OoLo33OtX8/E/ar GeAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=i1ORoEDYoebRABVjBEb0KVzPBm7/AGh+IvnwqXoPf18=; b=k9SPnx2RlK3Nr4B7vxSBOMzo0JkKDHdoqeCmmEfyv9DJEqUBKoEXzwfTfToXcxieQD YYoQLOZ3vkKRJAKAt89u+jg+XMqr5JpCxWfaTICgiwBnfdRTk7fTwRTrnPv1fxOKB2dX PIhVZPGj2o6C/vCdo6IoZSl23Bl7QcYaIzsJAGiUieSZtFVxsAQHf4ruFikkVQyeMI2i m+2WkgoV/dGiM6NL24KUlSZcVRC7WYl/DarKCwvDZGhVsFNLydd210zjJyxq55ucYaxG FH6B4MBdEdzBJ4BkpSI7GnxOZvnLb9yo59j+Whg5G2TQaU1xuAtsYeEOszB6Z+GSn/M2 gU0w== X-Gm-Message-State: ACgBeo3FvQDPE9fSyGikiHMxnzXmVQ/PQ57M4mzEl0cgdlfjfZM7WaX/ Z8tUmhDOCQIMq4kgbF/hq46qrdecRehJfQCQoGjk+A== X-Google-Smtp-Source: AA6agR7s2omNwBPQwT3pGLtZBlM3J4u6EeLLvR4pMXqrtwlWyZ7+z0WTCAEc7ZcQsnbCBcvBuvOrluzOF4Y7PIcJt9Y= X-Received: by 2002:a05:6a00:e1b:b0:537:7c74:c405 with SMTP id bq27-20020a056a000e1b00b005377c74c405mr3371228pfb.43.1662550674535; Wed, 07 Sep 2022 04:37:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henrik Holst Date: Wed, 7 Sep 2022 13:37:43 +0200 Message-ID: Subject: Re: read_only access attribute as optimizer hint To: Richard Biener Cc: GCC Development Content-Type: multipart/alternative; boundary="00000000000060912b05e814be65" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,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: --00000000000060912b05e814be65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener < richard.guenther@gmail.com>: > On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst > wrote: > > > > > > > > Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener < > richard.guenther@gmail.com>: > >> > >> > >> > >> > Am 06.09.2022 um 16:23 schrieb Henrik Holst < > henrik.holst@millistream.com>: > >> > > >> > =EF=BB=BFHi all, > >> > > >> > is there any reason why the access attribute is not used as hints to > the > >> > optimizer? > >> > > >> > If we take this ancient example: > >> > > >> > void foo(const int *); > >> > > >> > int bar(void) > >> > { > >> > int x =3D 0; > >> > int y =3D 0; > >> > > >> > for (int i =3D 0; i < 10; i++) { > >> > foo(&x); > >> > y +=3D x; // this load not optimized out > >> > } > >> > return y; > >> > } > >> > > >> > The load of X is not optimized out in the loop since the compiler > does not > >> > know if the external function foo() will cast away the const > internally. > >> > However changing the x variable to const as in: > >> > > >> > void foo(const int *); > >> > > >> > int bar(void) > >> > { > >> > const int x =3D 0; > >> > int y =3D 0; > >> > > >> > for (int i =3D 0; i < 10; i++) { > >> > foo(&x); > >> > y +=3D x; // this load is now optimized out > >> > } > >> > return y; > >> > } > >> > > >> > The load of x is now optimized out since it is undefined behaviour if > bar() > >> > casts the const away when x is declared to be const. > >> > > >> > Now what strikes me as odd however is that declaring the function > access > >> > attribute to read_only does not hint the compiler to optimize out the > load > >> > of x even though read_only is defined as being stronger than const > ("The > >> > mode implies a stronger guarantee than the const qualifier which, > when cast > >> > away from a pointer, does not prevent the pointed-to object from bei= ng > >> > modified."), so in the following code: > >> > > >> > __attribute__ ((access (read_only, 1))) void foo(const int *); > >> > > >> > int bar(void) > >> > { > >> > int x =3D 0; > >> > int y =3D 0; > >> > > >> > for (int i =3D 0; i < 10; i++) { > >> > foo(&x); > >> > y +=3D x; // this load not optimized out even though we have > set the > >> > access to read_only > >> > } > >> > return y; > >> > } > >> > > >> > The load of x should really be optimized out but isn't. So is this an > >> > oversight in gcc or is the access attribute completely ignored by the > >> > optimizer for some good reason? > >> > >> It=E2=80=99s ignored because it is not thoroughly specified. There=E2= =80=99s an > alternate representation the language Frontend can rewrite the attribute = to > to take advantage in optimization if it=E2=80=99s semantics matches. > >> > >> Richard > > > > Ok, didn't really understand the bit about the language Frontend but I > guess that you are talking about internal GCC things here and thus there = is > nothing that I as a GCC user can do to inform the optimizer that a variab= le > is read_only as a hint for external functions. And if so could it be > "thoroughly specified" to enable this type of optimization or is this just > "the way it is" ? > > Yes, there's currently nothing the user can do. Looking at the access > attribute specification it could be used > to initialize the middle-end used 'fn spec' specification - for > example the Fortran Frontend uses that to ferry > the guarantees by the 'INTENT' argument specification. > > Richard. > Ok, so patches to utilize the access attribute to inform the optimizer might be accepted? /HH > > > > > /HH > >> > >> > >> > >> > If there is no good reason for this then changing this to hint the > >> > optimizer should enable some nice optimizations of external functions > where > >> > const in the declaration is not cast away. > >> > > >> > Regards, > >> > Henrik Holst > --00000000000060912b05e814be65--