Re: read_only access attribute as optimizer hint
On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
wrote:
>
>
>
> Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener
> :
>>
>>
>>
>> > Am 06.09.2022 um 16:23 schrieb Henrik Holst :
>> >
>> > 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
Re: [RFC] database with API information
Ulrich Drepper via Gcc writes: > I talked to Jonathan the other day about adding all the C++ library APIs to > the name hint file now that the size of the table is not really a concern > anymore. > > Jonathan mentioned that he has to create and maintain a similar file for > the module support. It needs to list all the exported interfaces and this > is mostly a superset of the entries in the hint table. > > Instead of duplicating the information it should be kept in one place. > Neither file itself is a natural fit because the additional information > needed (e.g., the standard version information for the name hint table) is > not needed in the other location. > > Hence, let's use a simple database, a CSV file for simplicity, and generate > both files from this. Easily done, I have an appropriate script and a CSV > file with the information of both Jonathan's current export file and the > current state of the name hint table. > > The only detail that keeps me from submitting this right now is the way the > script is implemented. This is just a natural fit for a Python script. > The default installation comes with a csv module and there are nice ways to > adjust and output boilerplate headers like those needed in those files. > > It would be possible to create separate awk scripts (there is only one > Python script) but it'll be rather ugly and harder to maintain than the > Python version. > > Of course the problem is: I don't think that there is yet any maintainer > tool written in Python (except some release engineering tools). The > question is therefore: is it time to lift this restriction? I cannot today > imagine any machine capable of serving a gcc developer which doesn't also > have a Python implementation. As long as there is no dependency on exotic > modules I doubt that anything will break. FWIW, I agree it's past time to lift the no-Python restriction, and that Python is a natural fit for stuff like this. Thanks, Richard
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
>
Re: read_only access attribute as optimizer hint
On Wed, Sep 7, 2022 at 1:37 PM Henrik Holst
wrote:
>
>
>
> Den ons 7 sep. 2022 kl 09:48 skrev Richard Biener
> :
>>
>> On Tue, Sep 6, 2022 at 5:19 PM Henrik Holst
>> wrote:
>> >
>> >
>> >
>> > Den tis 6 sep. 2022 kl 16:47 skrev Richard Biener
>> > :
>> >>
>> >>
>> >>
>> >> > Am 06.09.2022 um 16:23 schrieb Henrik Holst
>> >> > :
>> >> >
>> >> > 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
Re: [RFC] database with API information
On 9/7/22 12:56, Richard Sandiford via Gcc wrote: > Ulrich Drepper via Gcc writes: >> I talked to Jonathan the other day about adding all the C++ library APIs to >> the name hint file now that the size of the table is not really a concern >> anymore. >> >> Jonathan mentioned that he has to create and maintain a similar file for >> the module support. It needs to list all the exported interfaces and this >> is mostly a superset of the entries in the hint table. >> >> Instead of duplicating the information it should be kept in one place. >> Neither file itself is a natural fit because the additional information >> needed (e.g., the standard version information for the name hint table) is >> not needed in the other location. >> >> Hence, let's use a simple database, a CSV file for simplicity, and generate >> both files from this. Easily done, I have an appropriate script and a CSV >> file with the information of both Jonathan's current export file and the >> current state of the name hint table. >> >> The only detail that keeps me from submitting this right now is the way the >> script is implemented. This is just a natural fit for a Python script. >> The default installation comes with a csv module and there are nice ways to >> adjust and output boilerplate headers like those needed in those files. >> >> It would be possible to create separate awk scripts (there is only one >> Python script) but it'll be rather ugly and harder to maintain than the >> Python version. >> >> Of course the problem is: I don't think that there is yet any maintainer >> tool written in Python (except some release engineering tools). The >> question is therefore: is it time to lift this restriction? I cannot today >> imagine any machine capable of serving a gcc developer which doesn't also >> have a Python implementation. As long as there is no dependency on exotic >> modules I doubt that anything will break. > > FWIW, I agree it's past time to lift the no-Python restriction, > and that Python is a natural fit for stuff like this. +1 for me! Martin > > Thanks, > Richard
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Sep 08, 2022)
Hi all, Here is the agenda for tomorrow's RISC-V GNU toolchain meeting. If you have any topics want to discuss or share, please let me know and I will add them to the agenda, thanks. Agenda: - Bump riscv-gnu-toolchain repo's submodules - RISC-V sub-extension supports progress RVV gcc support progress ZFH gcc support progress Zmmul support progress AIA support patches - Open topics RISC-V RVV C Intrinsic Vendor extension patches Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Time: Sep 08, 2022 11:00 PM Singapore Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics Join Zoom Meeting https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 11:00pThu, Sep 08 2022 12:00aFri, Sep 08 2022 PST/PDT, Pacific Standard Time (US) 8:00aThu, Sep 08 2022 9:00aThu, Sep 08 2022 PHILADELPHIA, United States, Pennsylvania 11:00aThu, Sep 08 2022 12:00aThu, Sep 08 2022 Paris, France 17:00pThu, Aug 11 2022 18:00pThu, Aug 11 2022BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20220317T223602Z TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20220713T134316Z DTSTART;TZID=Asia/Singapore:20220714T23 DTEND;TZID=Asia/Singapore:20220715T00 SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230323T16;INTERVAL=2;BYDAY=TH UID:ZOOM89393600951 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966 2\nOne tap mobile\n+6531651065\,\,89393600951#\,\,\,\,*899662# Singapore \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your location\n+65 3165 1065 Singapore\n+65 3158 7288 Singapo re\n+1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n +1 346 248 7799 US (Houston)\n+1 253 215 8782 US (Tacoma) \n+1 312 626 6799 US (Chicago)\n+1 646 558 8656 US (New York)\n+1 646 931 3860 US\n+1 301 715 8592 US (Washingto n DC)\nMeeting ID: 893 9360 0951\nPasscode: 899662\nFind your local numb er: https://us02web.zoom.us/u/kk9cyIPNJ\n\n LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj ZZMHhRQT09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
