read_only access attribute as optimizer hint
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
Re: read_only access attribute as optimizer hint
Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener <
richard.guent...@gmail.com>:
>
>
> > Am 06.09.2022 um 16:23 schrieb Henrik Holst <
> henrik.ho...@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
>
Re: read_only access attribute as optimizer hint
Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener <
richard.guent...@gmail.com>:
> On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
> wrote:
> >
> >
> >
> > Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener <
> richard.guent...@gmail.com>:
> >>
> >>
> >>
> >> > Am 06.09.2022 um 16:23 schrieb Henrik Holst <
> henrik.ho...@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
>
