DMD now incorporates a disassembler

[max haughton]

On Sunday, 9 January 2022 at 02:58:43 UTC, Walter Bright wrote:
>
> I've never seen one. What's the switch for gcc to do the same 
> thing?
>

For GCC/Clang you'd want -S (and then -masm=intel to make the 
output ~~beautiful to nobody but the blind~~ readable). This 
dumps the output to a file, which isn't exactly the same as what 
-vasm does, but I have already begun piping the -vasm output to a 
file since (say) hello world yields a thousand lines of output 
which is much easier to consume in a text editor.

To do it with ldc the flag is `--output-s`. I have opened a PR to 
make the ldc dmd-compatibility wrapper (`ldmd2`) mimic -vasm

Intel (and to a lesser extent Clang) actually annotate the 
generated text with annotations intended to be read by the humans.

e.g.

Intel C++ (which is in the process of being replaced with Clang 
relabeled as Intel C++) prints it's (hopeless unless you are 
using PGO, but still) estimates of the branch probabilities.
```

test      al, al                                        #5.8
je        ..B1.4        # Prob 22%                      #5.8
                         # LOE rbx rbp r12 r13 r14 r15
                         # Execution count [7.80e-01]
```

You can also ask the compiler to generate an optimization report 
inline with the assembly code. This *is* useful when tuning since 
you can tell what the compiler is or isn't getting right (e.g. 
find which roads to force the loop unrolling down). The Intel 
Compiler also has a reputation for having an arsenal of dirty 
tricks to make your code "faster" which it will deploy on the 
hope that you (say) don't notice that your floating point numbers 
are now less precise.

`-qopt-report-phase=vec` yields:
```
         # optimization report
         # LOOP WITH UNSIGNED INDUCTION VARIABLE
         # LOOP WAS VECTORIZED
         # REMAINDER LOOP FOR VECTORIZATION
         # MASKED VECTORIZATION
         # VECTORIZATION HAS UNALIGNED MEMORY REFERENCES
         # VECTORIZATION SPEEDUP COEFFECIENT 3.554688
         # VECTOR TRIP COUNT IS ESTIMATED CONSTANT
         # VECTOR LENGTH 16
         # NORMALIZED VECTORIZATION OVERHEAD 0.687500
         # MAIN VECTOR TYPE: 32-bits integer
vpcmpuq   k1, zmm16, zmm18, 6                           #5.5
vpcmpuq   k0, zmm16, zmm17, 6                           #5.5
vpaddq    zmm18, zmm18, zmm19                           #5.5
vpaddq    zmm17, zmm17, zmm19                           #5.5
kunpckbw  k2, k0, k1                                    #5.5
vmovdqu32 zmm20{k2}{z}, ZMMWORD PTR [rcx+r8*4]          #7.9
vpxord    zmm21{k2}{z}, zmm20, ZMMWORD PTR [rax+r8*4]   #7.9
vmovdqu32 ZMMWORD PTR [rcx+r8*4]{k2}, zmm21             #7.9
add       r8, 16                                        #5.5
cmp       r8, rdx                                       #5.5
jb        ..B1.15       # Prob 82%                      #5.5
```

People don't seem to care about SPEC numbers too much anymore, 
but the Intel Compilers still have many features for gaming 
standard test scores.

http://www.spec.org/cpu2006/results/res2007q3/cpu2006-20070821-01880.html If you looked at this, you'd think that Intel just managed a huge increase on `libquantum` which we can all use on our own code, but it turns out they worked out they can just tell the compiler to automagically parallelize the code, but still only have 1 nominal process.

https://stackoverflow.com/questions/61016358/why-can-gcc-only-do-loop-interchange-optimization-when-the-int-size-is-a-compile for more overfitting.

> Compilers that take a detour through an assembler to generate 
> code are inherently slower.

Certainly, although in my experience not by much. Time spent in 
the assembler in dominated by time spent in the linker, and just 
about everywhere else in the compiler (especially when you turn 
optimizations on). Hello World is about 4ms in the assembler on 
my machine.

GCC and Clang have very different architectures in this regard 
but end up being pretty similar in terms of compile times. The 
linker an exception to that rule of thumb, however, in that the 
LLVM linker is much faster than any current GNU offering.

>> It doesn't have a distinct IR like LLVM does but the final 
>> stage of the RTL is basically a 1:1 representation of the 
>> instruction set:
>
> That looks like intermediate code, not assembler.

It is the (final) intermediate code, but it's barely intermediate 
at this stage i.e. these are effectively just the target 
instructions printed with LISP syntax.

It's, helpfully, quite obfuscated unfortunately: Some of that is 
technical baggage, some of it is due to the way that GCC was 
explicitly directed to be difficult to consume).

I'm __not__ suggesting any normal programmer should use, just 
showing what GCC does since I mentioned LLVM.



Anyway, I've been playing with -vasm and I think it seems pretty 
good so far. There are some formatting issues which shouldn't be 
hard to fix at all (this is why we asked for some basic tests of 
the shape of the output), put I think I've only found one (touch 
wood) situation where it actually gets the instruction *wrong* so 
far.

Testing it has led to me finding some fairly bugs in the dmd 
inline assembler, which I am in the process of filing.