From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 57340385841A for ; Wed, 7 Sep 2022 12:03:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57340385841A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52b.google.com with SMTP id 29so14274246edv.2 for ; Wed, 07 Sep 2022 05:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=rMMrFXQF+ZxHvQ0qE9prT+EZUVZ3+38Vic03FJ+4ZWU=; b=FO8VYgtdRzlUkfMZiHS6E0gcVS+dRc1ooaKnyDGN7M9L62L5TiS77ql39KGr54khb2 TOUeofS/DzoZ6L9376IozXg/mR2+jnnQUreXOlB7SBMWM/+emcmX+7YgB9KGBww6jVuq ah8mu9bjpxNJG70LQwRODTK/rvfu1d7S1c++3BRAlADeWKqJ2uJIF1+CkU9bI8Hu4GZm LxkayuNc7/wYQNmtMmQ2UC/RN2ye/u/3iD21jiW+d1ER2APPVa51m2aRgHcUgasFEFl9 8VDLjw4loDgfnpcKI30lgxqE7FV31I0FPHdlK1ioF2D5sTMXZjtu4dwdx2N0cCJhvUDm fPag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=rMMrFXQF+ZxHvQ0qE9prT+EZUVZ3+38Vic03FJ+4ZWU=; b=h9pdoUxaTJuUR9U/NeJgn6Mn/iddTnXv9GGZtFxgB/bWaWvq+5mS/MtF5Eytul9KOx v6uRxrRaTtvGcQRY0trv9QBGEt0RwYgvp1FmTOGMcS5cPhunsjP8zzbw15vRDZvTU87I lQnG3AUty3iMyJi4V6Gn8UeDhrpYc7u9cZAzLvfkeYutV5W+dBjl5xGVjwH9+Gw/pZxK lm5qVKI+NHOnGCp3bymh93tHBujOG4CoFtxh18clBOpeXBibIE+/LncFvu67WAKFycC9 iObTfxBMVBrq5O2Mj/2M1JsD1eMnOhnFRSjF0k3Wa1EfR+D8CFhPYsZObr43XZEKOtds RFdA== X-Gm-Message-State: ACgBeo0AVdSYI0aVOFzc9vs9B866RZQxdtzDD1xOZAyf6z/nMomhE8bQ DOyPkeul8d+T5bnI0jE8Wtq9iIQK89xUo3onBsQ= X-Google-Smtp-Source: AA6agR4Nofi9SmLNvOmMZ0eDpuASFo9jMC57pRbEaMvfppkevTBvhtEsgnqZXBFisjBWbOsn1AoDuUXDI0RXL3ZabNQ= X-Received: by 2002:a05:6402:2b98:b0:43e:107:183d with SMTP id fj24-20020a0564022b9800b0043e0107183dmr2822979edb.366.1662552208998; Wed, 07 Sep 2022 05:03:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 7 Sep 2022 14:03:17 +0200 Message-ID: Subject: Re: read_only access attribute as optimizer hint To: Henrik Holst Cc: GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.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,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 Wed, Sep 7, 2022 at 1:37 PM Henrik Holst wrote: > > > > Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener : >> >> On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst >> wrote: >> > >> > >> > >> > Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener : >> >> >> >> >> >> >> >> > Am 06.09.2022 um 16:23 schrieb Henrik Holst : >> >> > >> >> > =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 d= oes not >> >> > know if the external function foo() will cast away the const intern= ally. >> >> > 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 a= ccess >> >> > attribute to read_only does not hint the compiler to optimize out t= he 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, w= hen cast >> >> > away from a pointer, does not prevent the pointed-to object from be= ing >> >> > 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 hav= e 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 t= he >> >> > 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 th= e 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 i= s 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 "th= oroughly specified" to enable this type of optimization or is this just "th= e 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 mi= ght be accepted? No, patches transforming the access attribute into appropriate 'fn spec' might be accepted. See attr-fnspec.h for how that works. Richard. > /HH >> >> >> > >> > /HH >> >> >> >> >> >> >> >> > If there is no good reason for this then changing this to hint the >> >> > optimizer should enable some nice optimizations of external functio= ns where >> >> > const in the declaration is not cast away. >> >> > >> >> > Regards, >> >> > Henrik Holst