* read_only access attribute as optimizer hint
@ 2022-09-06 14:22 Henrik Holst
2022-09-06 14:47 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Henrik Holst @ 2022-09-06 14:22 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read_only access attribute as optimizer hint
2022-09-06 14:22 read_only access attribute as optimizer hint Henrik Holst
@ 2022-09-06 14:47 ` Richard Biener
2022-09-06 15:19 ` Henrik Holst
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2022-09-06 14:47 UTC (permalink / raw)
To: Henrik Holst; +Cc: gcc
> Am 06.09.2022 um 16:23 schrieb Henrik Holst <henrik.holst@millistream.com>:
>
> 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?
It’s ignored because it is not thoroughly specified. There’s an alternate representation the language Frontend can rewrite the attribute to to take advantage in optimization if it’s semantics matches.
Richard
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read_only access attribute as optimizer hint
2022-09-06 14:47 ` Richard Biener
@ 2022-09-06 15:19 ` Henrik Holst
2022-09-07 7:48 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Henrik Holst @ 2022-09-06 15:19 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]
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>:
> >
> > 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?
>
> It’s ignored because it is not thoroughly specified. There’s an alternate
> representation the language Frontend can rewrite the attribute to to take
> advantage in optimization if it’s 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read_only access attribute as optimizer hint
2022-09-06 15:19 ` Henrik Holst
@ 2022-09-07 7:48 ` Richard Biener
2022-09-07 11:37 ` Henrik Holst
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2022-09-07 7:48 UTC (permalink / raw)
To: Henrik Holst; +Cc: GCC Development
On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
<henrik.holst@millistream.com> wrote:
>
>
>
> 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>:
>> >
>> > 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?
>>
>> It’s ignored because it is not thoroughly specified. There’s an alternate representation the language Frontend can rewrite the attribute to to take advantage in optimization if it’s 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" ?
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read_only access attribute as optimizer hint
2022-09-07 7:48 ` Richard Biener
@ 2022-09-07 11:37 ` Henrik Holst
2022-09-07 12:03 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Henrik Holst @ 2022-09-07 11:37 UTC (permalink / raw)
To: Richard Biener; +Cc: GCC Development
[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]
Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener <
richard.guenther@gmail.com>:
> On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
> <henrik.holst@millistream.com> wrote:
> >
> >
> >
> > 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>:
> >> >
> >> > 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?
> >>
> >> It’s ignored because it is not thoroughly specified. There’s an
> alternate representation the language Frontend can rewrite the attribute to
> to take advantage in optimization if it’s 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" ?
>
> 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
might be accepted?
/HH
>
> >
> > /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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: read_only access attribute as optimizer hint
2022-09-07 11:37 ` Henrik Holst
@ 2022-09-07 12:03 ` Richard Biener
0 siblings, 0 replies; 6+ messages in thread
From: Richard Biener @ 2022-09-07 12:03 UTC (permalink / raw)
To: Henrik Holst; +Cc: GCC Development
On Wed, Sep 7, 2022 at 1:37 PM Henrik Holst
<henrik.holst@millistream.com> wrote:
>
>
>
> Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener <richard.guenther@gmail.com>:
>>
>> On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
>> <henrik.holst@millistream.com> wrote:
>> >
>> >
>> >
>> > 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>:
>> >> >
>> >> > 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?
>> >>
>> >> It’s ignored because it is not thoroughly specified. There’s an alternate representation the language Frontend can rewrite the attribute to to take advantage in optimization if it’s 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" ?
>>
>> 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 might 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 functions where
>> >> > const in the declaration is not cast away.
>> >> >
>> >> > Regards,
>> >> > Henrik Holst
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-09-07 12:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-06 14:22 read_only access attribute as optimizer hint Henrik Holst
2022-09-06 14:47 ` Richard Biener
2022-09-06 15:19 ` Henrik Holst
2022-09-07 7:48 ` Richard Biener
2022-09-07 11:37 ` Henrik Holst
2022-09-07 12:03 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).