[Bug middle-end/32911] Function __attribute__ ((idempotent))

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[walters at verbum dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

Colin Walters <walters at verbum dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |walters at verbum dot org

--- Comment #2 from Colin Walters <walters at verbum dot org> 2012-05-15 15:51:13 UTC ---
More information about GObject requirements here:

https://bugzilla.gnome.org/show_bug.cgi?id=64994

Re: [Bug middle-end/32911] Function __attribute__ ((idempotent))

[Jan Hubicka]

Note that I was thinking of similar attribute for C++ iostream initialization code.
Currently every unit including iostream gets a call to the iostream constructor. With LTO
we merge the constructors together and get _alot_ of redundant calls to the construction
code.  Declaring that only first call is needed would save some (quite minor) startup
overehead. (overhead of iostream startup is large, but after inlning all together it
boils down to cca 7000 redundant calls in Mozilla startup that executes quite quickly)

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> 2012-05-15 15:57:29 UTC ---
Note that I was thinking of similar attribute for C++ iostream initialization
code.
Currently every unit including iostream gets a call to the iostream
constructor. With LTO
we merge the constructors together and get _alot_ of redundant calls to the
construction
code.  Declaring that only first call is needed would save some (quite minor)
startup
overehead. (overhead of iostream startup is large, but after inlning all
together it
boils down to cca 7000 redundant calls in Mozilla startup that executes quite
quickly)

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-15 15:59:40 UTC ---
Also note that internally we have looping const/looping pure that can be
optimized in this manner, so to large degree this is just matter of exporting
this out to user attributes + declaring sane behaviour on functions returning
void.

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[matthew at wil dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

Matthew Wilcox <matthew at wil dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthew at wil dot cx

--- Comment #6 from Matthew Wilcox <matthew at wil dot cx> ---
I actually have a use for a real idempotent function, that is f(f(x)) == f(x).
I think it's different from the behaviour wanted here which is more of an
initialiser functionality.

The concrete example is Linux's compound_head() macro which takes a pointer to
a struct page and returns a pointer to a (potentially different) struct page. 
A page is its own head, and calls to compound_head can be buried inside macros.

So I'd like gcc to know that given this program:

struct page *compound_head(struct page *) __attribute__((idempotent));

int g(struct page *page)
{
struct page *head = compound_head(page);
return page->refcount;
}

int f(struct page *page)
{
struct page *head = compound_head(page);
return g(head);
}

if it inlines g() into f(), it only needs to make one call to compound_head().

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[trass3r at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

Trass3r <trass3r at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trass3r at gmail dot com

--- Comment #7 from Trass3r <trass3r at gmail dot com> ---
OpenGL's bind functions are another example.
They don't return anything so can't be marked pure/const but any subsequent
calls with the same arguments are redundant.

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
It might also be worth comparing against the attributes [[unsequenced]] and
[[reproducible]] proposed for the C standard:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2956.htm

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-27 09:35 -------
The Java front-end has the same problem.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911