From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id D611F385800F for ; Tue, 6 Sep 2022 15:19:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D611F385800F 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-pl1-x629.google.com with SMTP id u22so11589865plq.12 for ; Tue, 06 Sep 2022 08:19:42 -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=PEn0MujNXzET3RZf1Js0Y4hiR8g/HKFoVvquplBjp0U=; b=t+T3IhX1QkM+Wz3oRyrOSOI6EYUiU0UpVpWRtEzkmfK2HFaC1gTaYh49DGvabHptAm +qY80+p3An+CSp1XXYLgIQdMlLXHDID1jml6LZCv8jTSYJBgX8OqRxaR5WU69DhHVHfU oetTNiW3bxpE6+QepLvpsjUIP8rdHvnXrabaI1KqCf+MuQr6+dQDt67D0mJzqWBiNTOd KDlONTPFfMIAQKl7uhAm0De9vKTYIjfbH3mo6bonOtTZfnUG6eyVGnY+BmxaFfWWROP0 eC1z+LPFTITZ7ssfZf9dUVnZ14E38/VOhes56CNBDzmXwBVPGyFkW+c/p2wnwpEQ6DF7 HtZA== 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=PEn0MujNXzET3RZf1Js0Y4hiR8g/HKFoVvquplBjp0U=; b=gQqYGTkkhc+habH6v+XW6ohs5j4SHje8Mw88ycfXVQFcavF3K+LuHOAd/Xzjn4I9FB PJiF8fIR7+748haTRfamle+0x9+F7aR7MKg9/94cfXLTCmQPtl5C7FU9OBrPBwb8NjgZ A31RPzBaaixc/hqKEOxyCSkz41Cy8M+vSTS0OOG9504i5bBsIGU0HlGsSNOtDEAosHTg n7jAeFwGhUZEIWnLnwIkmpFC8y+b3n+bnPplUSRce4S/BtBaf7bs3NDjzyWB9p60cG9A 5V6LLf/onW59Pa6pDVVGdBxqJsylAhcZd33dXO6TqbP6WojKZPd3D90jMk6ZVEeN6/9A mcMw== X-Gm-Message-State: ACgBeo0y8wZ3l5Cp6QRSUfEb25ptyu+RUMoO88WurWGzNPq6AYVHolWD 2TNgkimFTU3Qu9kXs4rT5UjPDxOQmbxVrfEbiXPSPQ== X-Google-Smtp-Source: AA6agR4G9G4QqrWrKJ8oAIb/5xuWDMkFgXexWuF+jK62JOAUmE/XCviU7TTar5DD7tGX34Sj9gCVDYQijTmwnRxdjgo= X-Received: by 2002:a17:90b:1652:b0:1fd:eca8:d2be with SMTP id il18-20020a17090b165200b001fdeca8d2bemr25554644pjb.79.1662477581753; Tue, 06 Sep 2022 08:19:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henrik Holst Date: Tue, 6 Sep 2022 17:19:30 +0200 Message-ID: Subject: Re: read_only access attribute as optimizer hint To: Richard Biener Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000b539fc05e803b962" X-Spam-Status: No, score=-1.3 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: --000000000000b539fc05e803b962 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 t= he > > 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 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 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 variable 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" ? /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 > --000000000000b539fc05e803b962--