public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/114979] New: Spurious eax clears
@ 2024-05-07 18:19 jacereda at gmail dot com
2024-05-07 18:31 ` [Bug target/114979] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: jacereda at gmail dot com @ 2024-05-07 18:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
Bug ID: 114979
Summary: Spurious eax clears
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jacereda at gmail dot com
Target Milestone: ---
Created attachment 58122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58122&action=edit
Code to reproduce the problem.
This is the version I'm using (although I've checked in several versions and
it's the same):
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gnu/store/vjjk375kysja1jz0837lypd09rdgs47c-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
When compiled with -O2, the attached program generates what I'd consider normal
code on clang, MSVC and even MinGW gcc, that is, something that looks like:
0000000000000040 <test>:
40: e8 eb ff ff ff call 30 <twodup>
45: e8 e6 ff ff ff call 30 <twodup>
4a: e8 e1 ff ff ff call 30 <twodup>
4f: e8 dc ff ff ff call 30 <twodup>
54: e8 d7 ff ff ff call 30 <twodup>
59: eb d5 jmp 30 <twodup>
Instead, it will generate:
0000000000000040 <test>:
40: 31 c0 xor %eax,%eax
42: e8 e9 ff ff ff call 30 <twodup>
47: 31 c0 xor %eax,%eax
49: e8 e2 ff ff ff call 30 <twodup>
4e: 31 c0 xor %eax,%eax
50: e8 db ff ff ff call 30 <twodup>
55: 31 c0 xor %eax,%eax
57: e8 d4 ff ff ff call 30 <twodup>
5c: 31 c0 xor %eax,%eax
5e: e8 cd ff ff ff call 30 <twodup>
63: 31 c0 xor %eax,%eax
65: eb c9 jmp 30 <twodup>
Declaring the functions as taking void will fix the problem. Same goes for
compiling with g++. I know void is the right thing in C, but I can't see any
reason to perform those clears.
Regards,
Jorge Acereda
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/114979] Spurious eax clears
2024-05-07 18:19 [Bug c/114979] New: Spurious eax clears jacereda at gmail dot com
@ 2024-05-07 18:31 ` pinskia at gcc dot gnu.org
2024-05-07 19:53 ` jacereda at gmail dot com
2024-05-07 19:59 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-07 18:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
From the ABI:
For calls that may call functions that use varargs or stdargs (prototype-less
calls or calls to functions containing ellipsis (...) in the declaration) %al
(16) is used as hidden argument to specify the number of vector registers used.
16) Note that the rest of %rax is undefined, only the contents of %al is
defined.
In this case you have a prototype-less call still. clang seems to recognize it
as one having a prototype here because of the final definition but I am not
100% sure if that is correct.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/114979] Spurious eax clears
2024-05-07 18:19 [Bug c/114979] New: Spurious eax clears jacereda at gmail dot com
2024-05-07 18:31 ` [Bug target/114979] " pinskia at gcc dot gnu.org
@ 2024-05-07 19:53 ` jacereda at gmail dot com
2024-05-07 19:59 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: jacereda at gmail dot com @ 2024-05-07 19:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
--- Comment #2 from Jorge Acereda <jacereda at gmail dot com> ---
Thanks for the prompt reply. I understand the behaviour for external functions,
but for static functions, isn't it a missed opportunity for optimization?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/114979] Spurious eax clears
2024-05-07 18:19 [Bug c/114979] New: Spurious eax clears jacereda at gmail dot com
2024-05-07 18:31 ` [Bug target/114979] " pinskia at gcc dot gnu.org
2024-05-07 19:53 ` jacereda at gmail dot com
@ 2024-05-07 19:59 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-07 19:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jorge Acereda from comment #2)
> Thanks for the prompt reply. I understand the behaviour for external
> functions, but for static functions, isn't it a missed opportunity for
> optimization?
The question comes is the function still a non-prototyped function or not even
if there is a definition. The answer is yes it is still a non-prototyped
function.
Anyways this does not matter that much since C23 changes () to be always
prototyped and the same as (void).
Also a zeroing of the register does only takes up icache space and does not get
issued as it is taken care of during rename on most (if not all) modern x86_64
cores.
So this is a very very minor space savings at best.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-05-07 19:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-07 18:19 [Bug c/114979] New: Spurious eax clears jacereda at gmail dot com
2024-05-07 18:31 ` [Bug target/114979] " pinskia at gcc dot gnu.org
2024-05-07 19:53 ` jacereda at gmail dot com
2024-05-07 19:59 ` pinskia 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).