Unoptimized Clang++ Code Generates Unneeded "Movl $0, -4(%Rbp)" in a Trivial Main()

Unoptimized clang++ code generates unneeded movl $0, -4(%rbp) in a trivial main()

TL;DR : In unoptimized code your CLANG++ set aside 4 bytes for the return value of main and set it to zero as per the C++(including C++11) standards. It generated the code for a main function that didn't need it. This is a side effect of not being optimized. Often an unoptimized compiler will generate code it may need, then doesn't end up needing it, and nothing is done to clean it up.

Because you are compiling with -O0 there is a very minimum of optimizations done on code (-O0 may remove dead code etc). Trying to understand artifacts in unoptimized code is usually a wasted exercise. The results of unoptimized code are extra loads and stores and other artifacts of raw code generation.

In this case main is special because in C99/C11 and C++ the standards effectively say that when reaching the outer block of main the default return value is 0. The C11 standard says:

5.1.2.2.3 Program termination

1 If the return type of the main function is a type compatible with int, a return from the
initial call to the main function is equivalent to calling the exit function with the value
returned by the main function as its argument;11) reaching the } that terminates the
main function returns a value of 0. If the return type is not compatible with int, the
termination status returned to the host environment is unspecified.

The C++11 standard says:

3.6.1 Main function

5) A return statement in main has the effect of leaving the main function (destroying any objects with automatic
storage duration) and calling std::exit with the return value as the argument. If control reaches the end
of main without encountering a return statement, the effect is that of executing
 return 0;

In the version of CLANG++ you are using the unoptimized 64-bit code by default has the return value of 0 placed at dword ptr [rbp-4].

The problem is that your test code is a bit too trivial to see how this default return value comes in to play. Here is an example that should be a better demonstration:

int main() {
    int a = 3;
    if (a > 3) return 5678;
    else if (a == 3) return 42;
}

This code has two exit explicit exit points via return 5678 and return 42; but there isn't a final return at the end of the function. If } is reached the default is to return 0. If we examine the godbolt output we see this:

main:                                   # @main
        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], 0        # Default return value of 0
        mov     dword ptr [rbp - 8], 3
        cmp     dword ptr [rbp - 8], 3        # Is a > 3
        jle     .LBB0_2
        mov     dword ptr [rbp - 4], 5678     # Set return value to 5678
        jmp     .LBB0_5                       # Go to common exit point .LBB0_5
.LBB0_2:
        cmp     dword ptr [rbp - 8], 3        # Is a == 3?
        jne     .LBB0_4
        mov     dword ptr [rbp - 4], 42       # Set return value to 42
        jmp     .LBB0_5                       # Go to common exit point .LBB0_5
.LBB0_4:
        jmp     .LBB0_5                       # Extraneous unoptimized jump artifact 
# This is common exit point of all the returns from `main`
.LBB0_5:
        mov     eax, dword ptr [rbp - 4]      # Use return value from memory
        pop     rbp
        ret

As one can see the compiler has generated a common exit point that sets the return value (EAX) from the stack address dword ptr [rbp-4]. At the beginning of the code dword ptr [rbp-4] is explicitly set to 0. In the simpler case, the unoptimized code still generates that instruction but goes unused.

If you build the code with the option -ffreestanding you should see the default return value for main no longer set to 0. This is because the requirement for a default return value of 0 from main applies to a hosted environment and not a freestanding one.

Apple clang -O1 not optimizing enough?

I suspect you were trying to see the addition happen.

int main(void)
{
    int a = 1 + 2;
    return 0;
}

but with optimization say -O2, your dead code went away

00000000 <main>:
   0:   2000        movs    r0, #0
   2:   4770        bx  lr

The variable a is local, it never leaves the function it does not rely on anything outside of the function (globals, input variables, return values from called functions, etc). So it has no functional purpose it is dead code it doesn't do anything so an optimizer is free to remove it and did.

So I assume you went to use no or less optimization and then saw it was too verbose.

00000000 <main>:
   0:   cf 93           push    r28
   2:   df 93           push    r29
   4:   00 d0           rcall   .+0         ; 0x6 <main+0x6>
   6:   cd b7           in  r28, 0x3d   ; 61
   8:   de b7           in  r29, 0x3e   ; 62
   a:   83 e0           ldi r24, 0x03   ; 3
   c:   90 e0           ldi r25, 0x00   ; 0
   e:   9a 83           std Y+2, r25    ; 0x02
  10:   89 83           std Y+1, r24    ; 0x01
  12:   80 e0           ldi r24, 0x00   ; 0
  14:   90 e0           ldi r25, 0x00   ; 0
  16:   0f 90           pop r0
  18:   0f 90           pop r0
  1a:   df 91           pop r29
  1c:   cf 91           pop r28
  1e:   08 95           ret

If you want to see addition happen instead first off don't use main() it has baggage, and the baggage varies among toolchains. So try something else

unsigned int fun ( unsigned int a, unsigned int b )
{
    return(a+b);
}

now the addition relies on external items so the compiler cannot optimize any of this away.

00000000 <_fun>:
   0:   1d80 0002       mov 2(sp), r0
   4:   6d80 0004       add 4(sp), r0
   8:   0087            rts pc

If we want to figure out which one is a and which one is b then.

unsigned int fun ( unsigned int a, unsigned int b )
{
    return(a+(b<<1));
}

00000000 <_fun>:
   0:   1d80 0004       mov 4(sp), r0
   4:   0cc0            asl r0
   6:   6d80 0002       add 2(sp), r0
   a:   0087            rts pc

Want to see an immediate value

unsigned int fun ( unsigned int a )
{
    return(a+0x321);
}

00000000 <fun>:
   0:   8b 44 24 04             mov    eax,DWORD PTR [esp+0x4]
   4:   05 21 03 00 00          add    eax,0x321
   9:   c3                      ret

you can figure out what the compilers return address convention is, etc.

But you will hit some limits trying to get the compiler to do things for you to learn asm likewise you can easily take the code generated by these compilations
(using -save-temps or -S or disassemble and type it in (I prefer the latter)) but you can only get so far on your operating system in high level/C callable functions. Eventually you will want to do something bare-metal (on a simulator at first) to get maximum freedom and to try instructions you cant normally try or try them in a way that is hard or you don't quite understand yet how to use in the confines of an operating system in a function call. (please do not use inline assembly until down the road or never, use real assembly and ideally the assembler not the compiler to assemble it, down the road then try those things).

The one compiler was built for or defaults to using a stack frame so you need to tell the compiler to omit it. -fomit-frame-pointer. Note that one or both of these can be built to default not to have a frame pointer.

../gcc-$GCCVER/configure --target=$TARGET --prefix=$PREFIX --without-headers --with-newlib  --with-gnu-as --with-gnu-ld --enable-languages='c' --enable-frame-pointer=no

(Don't assume gcc nor clang/llvm have a "standard" build as they are both customizable and the binary you downloaded has someone's opinion of the standard build)

You are using main(), this has the return 0 or not thing and it can/will carry other baggage. Depends on the compiler and settings. Using something not main gives you the freedom to pick your inputs and outputs without it warning that you didn't conform to the short list of choices for main().

For gcc -O0 is ideally no optimization although sometimes you see some. -O3 is max give me all you got. -O2 is historically where folks live if for no other reason than "I did it because everyone else is doing it". -O1 is no mans land for gnu it has some items not in -O0 but not a lot of good ones in -O2, so depends heavily on your code as to whether or not you landed in one/some of the optimizations associated with -O1. These numbered optimization things if your compiler even has a -O option is just a pre-defined list 0 means this list 1 means that list and so on.

There is no reason to expect any two compilers or the same compiler with different options to produce the same code from the same sources. If two competing compilers were able to do that most if not all of the time something very fishy is going on...Likewise no reason to expect the list of optimizations each compiler supports, what each optimization does, etc, to match much less the -O1 list to match between them and so on.

There is no reason to assume that any two compilers or versions conform to the same calling convention for the same target, it is much more common now and further for the processor vendor to create a recommended calling convention and then the competing compilers to often conform to that because why not, everyone else is doing it, or even better, whew I don't have to figure one out myself, if this one fails I can blame them.

There are a lot of implementation defined areas in C in particular, less so in C++ but still...So your expectations of what come out and comparing compilers to each other may differ for this reason as well. Just because one compiler implements some code in some way doesn't mean that is how that language works sometimes it is how that compiler author(s) interpreted the language spec or had wiggle room.

Even with full optimizations enabled, everything that compiler has to offer there is no reason to assume that a compiler can outperform a human. Its an algorithm with limits programmed by a human, it cannot outperform us. With experience it is not hard to examine the output of a compiler for sometimes simple functions but often for larger functions and find missed optimizations, or other things that could have been done "better" for some opinion of "better". And sometimes you find the compiler just left something in that you think it should have removed, and sometimes you are right.

There is education as shown above in using a compiler to start to learn assembly language, and even with decades of experience and dabbling with dozens of assembly languages/instruction sets, if there is a debugged compiler available I will very often start with disassembling simple functions to start learning that new instruction set, then look those up then start to get a feel from what I find there for how to use it.

Very often starting with this one first:

unsigned int fun ( unsigned int a )
{
    return(a+5);
}

unsigned int fun ( unsigned int a, unsigned int b )
{
    return(a+b);
}

And going from there. Likewise when writing a disassembler or a simulator for fun to learn the instruction set I often rely on an existing assembler since it is often the documentation for a processor is lacking, the first assembler and compiler for that processor are very often done with direct access to the silicon folks and then those that follow can also use existing tools as well as documentation to figure things out.

So you are on a good path to start learning assembly language I have strong opinions on which ones to or not to start with to improve the experience and chances of success, but I have been in too many battles on Stack Overflow this week, I'll let that go. You can see that I chose an array of instruction sets in this answer. And even if you don't know them you can probably figure out what the code is doing. "standard" installs of llvm provide the ability to output assembly language for several instruction sets from the same source code. The gnu approach is you pick the target (family) when you compile the toolchain and that compiled toolchain is limited to that target/family but you can easily install several gnu toolchains on your computer at the same time be they variations on defaults/settings for the same target or different targets. A number of these are apt gettable without having to learn to build the tools, arm, avr, msp430, x86 and perhaps some others.

I cannot speak to the why does it not return zero from main when you didn't actually have any return code. See comments by others and read up on the specs for that language. (or ask that as a separate question, or see if it was already answered).

Now you said Apple clang not sure what that reference was to I know that Apple has put a lot of work into llvm in general. Or maybe you are on a mac or in an Apple supplied/suggested development environment, but check Wikipedia and others, clang had a lot of corporate help not just Apple, so not sure what the reference was there. If you are on an Apple computer then the apt gettable isn't going to make sense, but there are still lots of pre-built gnu (and llvm) based toolchains you can download and install rather than attempt to build the toolchain from sources (which isn't difficult BTW).

What is the -4 for in assembler: movl $1, -4(%rbp)

-4 / -8 / -12 bytes relative to the address held in rbp, which is the pointer to the top of the stack (which grows downward). 4 bytes / 32 bits because that is the size of int on your machine.

Prevent clang from replacing my code with library calls

Its seems like a syntax bug in clang. You must use optimization flag together with the no-builtin flag.

The following command produces assembly with a call to memcopy:

arm-linux-androideabi-clang -S myMemcpy.c -fno-builtin

The following command produces assembly without a call to memcopy:

arm-linux-androideabi-clang -S myMemcpy.c -fno-builtin -O1

The no-builtin flag is coupled with the optimization flag.

Unoptimized Clang++ Code Generates Unneeded "Movl $0, -4(%Rbp)" in a Trivial Main()