[Bug c/114979] New: Spurious eax clears

[Bug c/114979] New: Spurious eax clears

[jacereda at gmail dot com]

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

[Bug target/114979] Spurious eax clears

[pinskia at gcc dot gnu.org]

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.

[Bug target/114979] Spurious eax clears

[jacereda at gmail dot com]

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?

[Bug target/114979] Spurious eax clears

[pinskia at gcc dot gnu.org]

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.