public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/65534] New: tailcall not optimized away
@ 2015-03-24 2:19 aldot at gcc dot gnu.org
2015-03-24 7:12 ` [Bug middle-end/65534] " hubicka at ucw dot cz
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: aldot at gcc dot gnu.org @ 2015-03-24 2:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
Bug ID: 65534
Summary: tailcall not optimized away
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aldot at gcc dot gnu.org
CC: hubicka at ucw dot cz, rguenth at gcc dot gnu.org
Maybe this could be optimized by a thunk or by creating the alias automatically
or the like? Or is tailcall supposed to do this already?
trunk@221345
$ gcc -Os -c missed-opt.c -o missed-opt.plain.o
$ gcc -Os -c missed-opt.c -o missed-opt.manual.o -DOPTIMIZE_MANUALLY
$ size missed-opt.*.o
text data bss dec hex filename
86 0 0 86 56 missed-opt.manual.o
104 0 0 104 68 missed-opt.plain.o
$ cat missed-opt.c ; echo EOF
static int fd = -1;
extern void dummy0(void);
extern void dummy1(int);
extern void setutent(void) __attribute__ ((__nothrow__ ));
extern __typeof (setutent) setutent __asm__ ("" "__GI_setutent")
__attribute__ ((visibility ("hidden")));
extern void getutent(void) __attribute__ ((__nothrow__ ));
extern __typeof (getutent) getutent __asm__ ("" "__GI_getutent")
__attribute__ ((visibility ("hidden")));
static void __setutent_unlocked(void) {
if (fd < 0) {
dummy0();
if (fd < 0) {
dummy0();
if (fd < 0)
return;
}
return;
}
dummy1(fd);
}
#ifndef OPTIMIZE_MANUALLY
void setutent(void) {
((void)0);
__setutent_unlocked();
((void)0);
}
#else
extern __typeof (__setutent_unlocked) setutent
__attribute__ ((alias ("__setutent_unlocked")));
#endif
extern __typeof (setutent) __EI_setutent __asm__("" "setutent");
extern __typeof (setutent) __EI_setutent
__attribute__((alias ("" "__GI_setutent")));
static void __getutent_unlocked(void) {
if (fd < 0)
__setutent_unlocked();
}
#ifndef OPTIMIZE_MANUALLY
void getutent(void) {
((void)0);
__getutent_unlocked();
((void)0);
}
#else
extern __typeof (__getutent_unlocked) getutent
__attribute__ ((alias ("__getutent_unlocked")));
#endif
extern __typeof (getutent) __EI_getutent __asm__("" "getutent");
extern __typeof (getutent) __EI_getutent
__attribute__((alias ("" "__GI_getutent")));
EOF
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/65534] tailcall not optimized away
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
@ 2015-03-24 7:12 ` hubicka at ucw dot cz
2015-03-24 7:21 ` hubicka at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: hubicka at ucw dot cz @ 2015-03-24 7:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
--- Comment #1 from Jan Hubicka <hubicka at ucw dot cz> ---
> #ifndef OPTIMIZE_MANUALLY
> void setutent(void) {
> ((void)0);
> __setutent_unlocked();
> ((void)0);
> }
> #else
> extern __typeof (__setutent_unlocked) setutent
> __attribute__ ((alias ("__setutent_unlocked")));
> #endif
I do not think GCC can safely optimize this, becuase in the first
case &setutent != &__setutent_unlocked, wile in the optimized
case the addresses are equal.
This is something we looked into with Martin Liska but was late for
GCC 5. We have -fmerge-all-constants, we may want to introduce something
like -fmerge-all-functions declaring that this special case does not matter
(curiously enough there is real world code that actually compares the addresses
of otherwise equivalent functions, like in GCC PCH implementation).
Second thing is to make ipa-ICF to discover wrappers and consider them
semantically equivalent to their target. Something I also discussed with
Martin.
So hopefully early next stage1 this can be implemented.
Honza
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/65534] tailcall not optimized away
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
2015-03-24 7:12 ` [Bug middle-end/65534] " hubicka at ucw dot cz
@ 2015-03-24 7:21 ` hubicka at gcc dot gnu.org
2015-07-09 13:21 ` aldot at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-03-24 7:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-03-24
CC| |hubicka at gcc dot gnu.org,
| |mliska at suse dot cz
Target Milestone|--- |6.0
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/65534] tailcall not optimized away
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
2015-03-24 7:12 ` [Bug middle-end/65534] " hubicka at ucw dot cz
2015-03-24 7:21 ` hubicka at gcc dot gnu.org
@ 2015-07-09 13:21 ` aldot at gcc dot gnu.org
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
2023-03-31 11:56 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: aldot at gcc dot gnu.org @ 2015-07-09 13:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
--- Comment #2 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #1)
> > #ifndef OPTIMIZE_MANUALLY
> > void setutent(void) {
> > ((void)0);
> > __setutent_unlocked();
> > ((void)0);
> > }
> > #else
> > extern __typeof (__setutent_unlocked) setutent
> > __attribute__ ((alias ("__setutent_unlocked")));
> > #endif
>
> I do not think GCC can safely optimize this, becuase in the first
> case &setutent != &__setutent_unlocked, wile in the optimized
> case the addresses are equal.
Note that __setutent_unlocked is static, so i don't see how this specific case
would prevent optimization?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/65534] tailcall not optimized away
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
` (2 preceding siblings ...)
2015-07-09 13:21 ` aldot at gcc dot gnu.org
@ 2021-05-04 12:31 ` rguenth at gcc dot gnu.org
2023-03-31 11:56 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/65534] tailcall not optimized away
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
` (3 preceding siblings ...)
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
@ 2023-03-31 11:56 ` marxin at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-03-31 11:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65534
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
Status|ASSIGNED |NEW
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-03-31 11:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-24 2:19 [Bug c/65534] New: tailcall not optimized away aldot at gcc dot gnu.org
2015-03-24 7:12 ` [Bug middle-end/65534] " hubicka at ucw dot cz
2015-03-24 7:21 ` hubicka at gcc dot gnu.org
2015-07-09 13:21 ` aldot at gcc dot gnu.org
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
2023-03-31 11:56 ` marxin at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).