Peek Into The Compiler’s Code — Lots Of Compilers

We don’t know what normal people argue about, but we know we spend a lot of time arguing about the best microcontroller, which editor is the best, and what language or compiler does the best job. The problem with all those compilers is getting them loaded and digging into the generated code. If you too spend your time thinking about those things, you ought to have a look at [Matt Godbolt’s] Compiler Explorer. We know that hosting an IDE-like web page and compiling code is old hat — although [Matt’s] site has been around quite some time. But [Matt’s] doing it differently. The code you build on the left hand pane shows up as assembly language on the right hand side.

There are plenty of options, too. For example, here’s a bit of C code from the site’s example:

int square(int num) {
   return num * num;
}

Here’s the corresponding assembly from gcc 9.2 for x86-64:

square:
  push rbp
  mov rbp, rsp
  mov DWORD PTR [rbp-4], edi
  mov eax, DWORD PTR [rbp-4]
  imul eax, eax
  pop rbp
  ret

However, ARM64 gcc 8.2 outputs:

square:
  sub sp, sp, #16
  str w0, [sp, 12]
  ldr w1, [sp, 12]
  ldr w0, [sp, 12]
  mul w0, w1, w0
  add sp, sp, 16
  ret

There are options for many compilers including AVR. 6502, and MIPS. Even more interesting is there is support for many other languages ranging from FORTRAN to Rust and Go. It is a nice touch that the source code lines get colors that match the region of the disassembly that corresponds to that line.

As a side note, you can click the Output button at the bottom and actually run your test program, if you like. If you are interested in how the system works, there’s a document that describes how the system leverages Amazon’s elastic cloud and Docker. Of course, [Matt’s] made a lot of changes since that document was written, but at least it will give you a general idea, plus you can always go dig around in his GitHub repo.

We’ve gotten to the point where we sort of enjoy these web-based playgrounds for learning purposes. We probably wouldn’t write our million dollar super secret code on it, but who are we kidding? No one really wants to read the source to our latest IoT garage door.

12 thoughts on “Peek Into The Compiler’s Code — Lots Of Compilers

  1. Rule #1 when analyzing generated code: debug code is worthless. Unfortunately the default example you posted is debug code. It would be more interesting, and also much simpler to understand, if you posted the examples with -O2 in the compiler options.

    Anyway, I love this amazing tool. I use it frequently at work. Beside checking differences between compilers and what code is most optimized, last time I discovered an obscure compiler option that actually really makes a difference.

    Check the difference between these two:
    https://godbolt.org/z/qx7-aZ
    https://godbolt.org/z/ULnyd_

    1. It was just the stock example provided by the site, but sure. Honestly, I think the optimization level would depend on what you are trying to understand — the function of the code, or what the compiler is doing exactly to your code that you may want to further optimize or you suspect the code generation is bad. But sure, you may want to use different options than the stock example.

  2. I am constrained to point out that debug cose, while not optimal code, is built so that it is possible to point to a set of (usually contiguous) instructions that implement each statement, with no overlaps. In fully optimized code, the attribution of generated code to specific source lines is not always possible. The attributions are generated by the compiler itself so that debugs can single-step by statement. In optimized code, the concept has little meaning in many cases though the compiler does the best it can. This difficulty is reflected fully in the Compiler Explorer.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.