This is conflating two different things over the life of the MACRO-32
language. It certainly started out as a macro assembler, but with the
introduction of the Alpha, DEC turned it into a true compiler (where
the source language happens to be VAX assembly language) that
generated native code for whatever machine it was compiled for: VAX or
Alpha; using the GEM backends.
The confusion arises because the name VAX MACRO was used for two completely independent and very different software tools.
The first VAX MACRO was the conventional assembler for VAX/VMS, developed in the mid-1970s. It had conventional macroinstruction capabilities, hence the name.
An inconveniently large amount of the VAX/VMS operating system code was written in VAX assembly language. Dave Cutler didn't believe in using higher level languages for system code, and he despised BLISS (DEC's standard HLL language for software product development) in particular. To migrate VMS to Alpha it was decided that the quickest and least error-prone path was to write a compiler front end that takes VAX MACRO syntax and generates expanded intermediate language (EIL) for the GEM compiler back end. GEM then generates the Alpha code and writes it into an object file. This work was done circa 1990. The name "VAX MACRO" was used for this compiler as well as for the previous assembler.
When Compaq started the port to Itanium, they employed the same
technique; this was maintained by HP.
No further work needed to be done in the VAX MACRO compiler front end to support Itanium. All that needed to be done was to add Itanium code generation capability to the GEM back end. After that all GEM-based compilers acquired Itanium code generation capability. That is the big advantage of having a common back end for all compilers. Over its lifetime GEM could generate object files for the MIPS, Alpha, and IA-32 machine architectures and for the VMS, Ultrix, OSF-1, and Windows operating systems.
VSI has shifted to using LLVM as their compiler backend for the x86_64
port, with ELF as the executable file format (and presumably for
object files as well). As I understand the current state of affairs,
there is a GEM to LLVM layer that interfaces between the still-GEM
output of compiler frontends and the LLVM backend, that performs
native code generation. Macro, in particular, bypasses most of the
LLVM optimization layer.
VAX MACRO also bypassed most of GEM's optimization layer as well. And yes, most (if not all) of the legacy OpenVMS compilers use a GEM-to-LLVM IL translator. VSI has more than enough on their plate without taking on a wholesale rewrite of the IL generators in the compiler front ends.
-Paul W.