[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 c/32911] New: Function __attribute__ ((idempotent))

[gnu at behdad dot org]

In GNOME's gobject object-oriented code, each type has a "get_type" function. 
Something like, eg:

GType
pango_layout_line_get_type(void)
{
  static GType our_type = 0;

  if (our_type == 0)
    our_type = g_boxed_type_register_static (I_("PangoLayoutLine"),
                           (GBoxedCopyFunc) pango_layout_line_ref,
                           (GBoxedFreeFunc) pango_layout_line_unref);
  return our_type;
}

Since these functions are called quite frequently (as part of casts among other
things), people have started marking them with __attribute__((const)) so the
compiler can optimize away multiple calls to them.  However, there is a down
side to it.  Sometimes one needs to make sure the type is registered, so they
call the _get_type() function to ensure that, but the compiler, seeing the
((const)) attribute, optimizes away the call.

This is of course a bug to mark functions with side-effects as ((const)). 
That's why a new function attribute like "idempotent" is useful.  What it means
is that subsequent calls to this function return the same value as the first
call, have no side-effect, and can be optimized away, but not the first call...

Thanks,


-- 
           Summary: Function __attribute__ ((idempotent))
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gnu at behdad dot org


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

[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