From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 6865C3858CDA for ; Tue, 6 Sep 2022 14:47:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6865C3858CDA 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-x62a.google.com with SMTP id lz22so2998555ejb.3 for ; Tue, 06 Sep 2022 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date; bh=oqOSU4PIgywbrCQgt3i1PSLaMZTMh7VZvoUW+tWC0dA=; b=gFox5Hki9Fur+8KMjcGB9Kqz7dmbirs6K+rd7mD5kV4PCv6vh+ahUq1PHMTrmoA7tS A4Tem0Ynst3k87sh7Uyx2Ld9Zd/fM8BGYZUOPLcxzUNv9hLLL/DXg6lrFCJRDjd+9x/m SpXyD5BNW1301fDHqcOOUKkVHqRDT1QGoSyc1RqP3iTDb/wHqhWiFthjRoRcll5u0cDe teLEy96VVP861WSpVfWNMGZs+PD2SA6WN6uEHm4LKKUj9XboLGqgfigMHaT3lwM40Yqk 9Ugjh4Ulng6+k0m1JolsLIpG6foUavueuNPBi9N8LHqfhIwHC/Q2jok4z7BGb5ycLPMe js8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=oqOSU4PIgywbrCQgt3i1PSLaMZTMh7VZvoUW+tWC0dA=; b=io2fUelmVLVJme9igzQbHRS305U57sZdWJW03ULmotqqjd2SN7gttFTCmSZ5S+4zUO eeCuy0TNszZ/tm1NP4dkrF7bMaXZJKw/U+fu62mbBSBRCIiZROIZrOGWp+u7mpCXtTYC bffzpORfnGL1qwMbRaOg6nEVhMC2EGb3XvgMws+6oPqjoBq/ETDann8BSTzvquzihdDy M5I9ff6t7kiSN7+eCFS8EVpoJYpO9dbH9cd/j2lkAOiUYKHMIJGl1BPZMj9n4c9sJUUi 39rywH8cQCNLP112ZPT4DNA2Uca3G8LUE/sfsVE9X6pKV9UPzygZeGrLMRd9iH3nsWwb Ka6A== X-Gm-Message-State: ACgBeo3KT8EzpIJ/bgc8zQNc4cIAKooabMibHg5YfpQAkQMoGngQcljr N3e2LwvcnDAdcORsImJ7AIE/++2Rxp8= X-Google-Smtp-Source: AA6agR48rIAYhVk8Nfz4EKDQQ7HrDLxwVQgIAvzk8Ljku+rSNIa7myzIv+nZcGrRKNjG0YrCgoOnyw== X-Received: by 2002:a17:906:6a0b:b0:76f:a2e:10fc with SMTP id qw11-20020a1709066a0b00b0076f0a2e10fcmr2221027ejc.521.1662475648580; Tue, 06 Sep 2022 07:47:28 -0700 (PDT) Received: from smtpclient.apple (dynamic-095-115-092-162.95.115.pool.telefonica.de. [95.115.92.162]) by smtp.gmail.com with ESMTPSA id j2-20020a17090623e200b0073d638a7a89sm6827793ejg.99.2022.09.06.07.47.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Sep 2022 07:47:28 -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: read_only access attribute as optimizer hint Date: Tue, 6 Sep 2022 16:47:27 +0200 Message-Id: References: Cc: gcc@gcc.gnu.org In-Reply-To: To: Henrik Holst X-Mailer: iPhone Mail (19G82) X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 06.09.2022 um 16:23 schrieb Henrik Holst = : >=20 > =EF=BB=BFHi all, >=20 > is there any reason why the access attribute is not used as hints to the > optimizer? >=20 > If we take this ancient example: >=20 > void foo(const int *); >=20 > int bar(void) > { > int x =3D 0; > int y =3D 0; >=20 > for (int i =3D 0; i < 10; i++) { > foo(&x); > y +=3D x; // this load not optimized out > } > return y; > } >=20 > 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: >=20 > void foo(const int *); >=20 > int bar(void) > { > const int x =3D 0; > int y =3D 0; >=20 > for (int i =3D 0; i < 10; i++) { > foo(&x); > y +=3D x; // this load is now optimized out > } > return y; > } >=20 > 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. >=20 > 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 cas= t > away from a pointer, does not prevent the pointed-to object from being > modified."), so in the following code: >=20 > __attribute__ ((access (read_only, 1))) void foo(const int *); >=20 > int bar(void) > { > int x =3D 0; > int y =3D 0; >=20 > for (int i =3D 0; i < 10; i++) { > foo(&x); > y +=3D x; // this load not optimized out even though we have set t= he > access to read_only > } > return y; > } >=20 > 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=99= s an alternate representation the language Frontend can rewrite the attribut= e to to take advantage in optimization if it=E2=80=99s semantics matches. Richard=20 > If there is no good reason for this then changing this to hint the > optimizer should enable some nice optimizations of external functions wher= e > const in the declaration is not cast away. >=20 > Regards, > Henrik Holst