Respectfully—and I truly mean this!—this is nowhere near enough to attain parity with GCC and LLVM. I don't see any SSA form, to name just one of many issues.

GCC 4.0, which introduced the SSA-based GIMPLE, was released in 2004, which is roughly around the same time you mentioned that the optimization quality started to diverge. This is not an accident. At the time, lots of compilers thought that they could continue to compete with GCC without doing SSA-based optimizations. GCC crushed them all one by one.

I forgot to add SROA to the list. DMD does a limited form of SROA I wrote as a proof of concept, it should be generalized.

https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...

I've also written a loop unroller, but it can be improved:

https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...

My evaluation was based on comparing the code gen output of the various compilers, not looking at how they were achieved.

As for SSA, DMD's optimizer is based on an intermediate representation that is a binary tree. A binary tree is a form of SSA - each operator node is a value assigned once and never modified.

> Respectfully

No worries. I'm used to people telling me I can't do things :-)

Is the intermediate representation documented/described somewhere?

"Use the Source, Luke!"

https://github.com/DigitalMars/Compiler/blob/master/dm/src/d...

Well, I did look at it, but it was difficult to figure out how control-flow is structured. Is every “basic block” a single “el”, or is the CFG structured inside the binary tree? How are variables handled? Are there load expressions? Do you use something similar to phi-nodes to merge values from different branches? How do you do analysis? Do you walk over the expression tree and store the results (e.g. in constant propagation) on the nodes themselves? Do you use a separate cache/hashmap?

Basic blocks form a linked list (block*), and each basic block has a tree of elem's. Control flow is done with the basic block "predecessor" and "successor" lists.