Bug 32911 - Function __attribute__ ((idempotent))
Summary: Function __attribute__ ((idempotent))
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-27 06:33 UTC by Behdad Esfahbod
Modified: 2012-05-15 15:59 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Behdad Esfahbod 2007-07-27 06:33:47 UTC
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,
Comment 1 Andrew Pinski 2007-07-27 09:35:41 UTC
The Java front-end has the same problem.
Comment 2 Colin Walters 2012-05-15 15:51:13 UTC
More information about GObject requirements here:

https://bugzilla.gnome.org/show_bug.cgi?id=64994
Comment 3 Jan Hubicka 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)
Comment 4 Jan Hubicka 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.