[Bug middle-end/32911] Function __attribute__ ((idempotent))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 Trass3r changed: What|Removed |Added CC||trass3r at gmail dot com --- Comment #7 from Trass3r --- 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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 Matthew Wilcox changed: What|Removed |Added CC||matthew at wil dot cx --- Comment #6 from Matthew Wilcox --- 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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911 --- Comment #5 from Philip Withnall --- Bug filed against Clang with the same request here: https://bugs.llvm.org/show_bug.cgi?id=34600
[Bug middle-end/32911] Function __attribute__ ((idempotent))
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))
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))
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))
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))
--- 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