From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id B427D3851A87 for ; Tue, 6 Sep 2022 14:22:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B427D3851A87 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-x631.google.com with SMTP id x1so7105616plv.5 for ; Tue, 06 Sep 2022 07:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=millistream-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=AgC/UoctEo0IYyJ5p4L+jvDC9EHR5nu6y661yfSztC4=; b=IGRwbOOiZ9lTLSonGyp1F47HBT5gWV4XDnOv6A6Ji2s9eGeMMbuXsTf8d2eACX8wN+ 67B+MJBgVofAPFCdxwOWGYS+WKB1oH7ZffLGsFzTwfUJIaEGJJRESe/cVORtqnGg195L xSv09Va0qDgbiiHaKaGXJ+vTK9jDapgnY34f4RSzrqPpaT9UeuZN53RiZgvyyl3FIRoU fru03hn82sF/3vV8/rv8fyicaTr9fb1Q3aNPf8EorF0Um8zKZ75HrcB4hiKCZZEe2b/C 88ccKRZnr6WiEE7N2L1hoRnHZs9uUckQtJhm/uy1JIJPTiyAc4V3WwOq9dX+x87ZDwy9 I3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=AgC/UoctEo0IYyJ5p4L+jvDC9EHR5nu6y661yfSztC4=; b=c5te7W7s6zyjF4v/rWkhjtQRjNdeVzFfLvGKkqJViTjCQ55zu4jTBVkEGxkcz4Zh1c Bcow2z7B3/8cPGzNv+yHg+Hptu3MWMPaSRW7pEiTPlvkTAadBNg/mQsI3X+FA0wzlHQs LrYqsXaRf0WxNWDqIDdepOXP+I2w75ovsrUudOAk7mlwZREEIa1beJf4n5GRX8n7mJ0y djne7uQPmP8F+aJNXIO8q0YC9nnYqTGJjvBvRqybx0AeT72FzAdK7QJh0vT1ZAlKf39T PuJcx/2CJuTCQB3VbveuZR+pC+9m/sFg6RpM0yhWMGMq7wn6IzQ1ehdnBGZmUYSexXV5 P6LQ== X-Gm-Message-State: ACgBeo2qbeqvDMzU6YnhFl+c8a1JzYObNOxsXP0cqH0A5RXWURiqP2AV QOx1rCTLvP8wWT1N0gB2rXI69Yg3rvrvXA8myzatpwQuQZY= X-Google-Smtp-Source: AA6agR5k+oAgdvPw3synLsQP2zNHTgxfJEPOTadDVD0akWbpB8x6BV6v4lIyhwG/064WFhm8IWH4/mGztbkfuSPSZtc= X-Received: by 2002:a17:903:22c3:b0:176:b658:4eb6 with SMTP id y3-20020a17090322c300b00176b6584eb6mr8589067plg.56.1662474137170; Tue, 06 Sep 2022 07:22:17 -0700 (PDT) MIME-Version: 1.0 From: Henrik Holst Date: Tue, 6 Sep 2022 16:22:06 +0200 Message-ID: Subject: read_only access attribute as optimizer hint To: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000650d7005e802ec2e" X-Spam-Status: No, score=-0.6 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: --000000000000650d7005e802ec2e Content-Type: text/plain; charset="UTF-8" Hi 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 = 0; int y = 0; for (int i = 0; i < 10; i++) { foo(&x); y += 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 = 0; int y = 0; for (int i = 0; i < 10; i++) { foo(&x); y += 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 = 0; int y = 0; for (int i = 0; i < 10; i++) { foo(&x); y += 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? 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 --000000000000650d7005e802ec2e--