From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 1FBCE3858D28 for ; Wed, 7 Sep 2022 07:48:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1FBCE3858D28 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-ej1-x62e.google.com with SMTP id u9so28478921ejy.5 for ; Wed, 07 Sep 2022 00:48:34 -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=ZeH1808d7cKLSh595XX/Oclkrf/oXFXk6mznjNpCHng=; b=cL4OQfx5/l13Fl8Y6kI2Sz5a6R81HTneub/en519rlpizQFbykryQb/uFI3BXtQF8s 6ly188rqEleCVgPJAj58K1oM3z7RCo3pIUPPGVqrG/hyxo1wSllKOcVFG/y1inamlCIe EBpr6q+zPNpO+uKZTFj1sK97PUQMgoRU3h7MpB+zdvb479fN6g+/VX1Ud7yAziI65BEz VxJqgO5xROuGZXdYN3059pFkqZDUWqMHOYMBYlJh2juclq5UnATwjAkGnaJzn/24680m IfxMhpa0rPn2nr86S02J0E3ebCWM4eqfS1JbwLua8HHnHdqYNbazJ6hiC43EYgH8eA71 h1jA== 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=ZeH1808d7cKLSh595XX/Oclkrf/oXFXk6mznjNpCHng=; b=CFqftLcvXYSnjvezF4cdN55pBB070j7zHTPzYSoaPGNX1+lxx/OCkJPxk65wqBSPe0 xo1u9tHke2d0CYnPghLd3d/obByL/0quFgERS2UKA2IMn6KsjMZEYhab9e2oVRpcriaH Q5FTQw+ub2LFesLIc3uJW8xQEf9rwU+d2PS6ec/4eN7DVNCDXEcDaZUolWKDsou9xmKS 0rE75pkoL3pQTKqnW0CguiWPvxR9vEPv4hLv6NRIxzkCkROobanhvfwZpdzjIRhIFecg mkMhhax4RKAcgKVPKpXDN+hbRwlmhH4z0EfOcsaXWkIfjZiTBGGjPk9gG5mlOb9K80Ac j+1w== X-Gm-Message-State: ACgBeo2gb9MRR9UzbFdLej9v6cWtjFRcFqf2uboA577k0a58NEFbWttJ MMJ5w4GddN7vz/2UYyZF3Rd10L/koFqBRSpJaBM= X-Google-Smtp-Source: AA6agR5K3P5vraGA5wsgTjotFOxzuEG2wYWXC95JHGo/phdsJyF76a5nsRa56oQ2RLTLV6okQkN8yD7+/XvH5w/t08k= X-Received: by 2002:a17:906:5d16:b0:74c:32ce:208b with SMTP id g22-20020a1709065d1600b0074c32ce208bmr1497522ejt.594.1662536912768; Wed, 07 Sep 2022 00:48:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 7 Sep 2022 09:48:20 +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=-1.6 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 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 does= not >> > know if the external function foo() will cast away the const internall= y. >> > 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 acce= ss >> > 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 ("T= he >> > mode implies a stronger guarantee than the const qualifier which, when= cast >> > away from a pointer, does not prevent the pointed-to object from being >> > 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 s= et 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 a= ttribute to to take advantage in optimization if it=E2=80=99s semantics mat= ches. >> >> Richard > > Ok, didn't really understand the bit about the language Frontend but I gu= ess that you are talking about internal GCC things here and thus there is n= othing that I as a GCC user can do to inform the optimizer that a variable = is read_only as a hint for external functions. And if so could it be "thoro= ughly specified" to enable this type of optimization or is this just "the w= ay 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. > > /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