[Info-vax] Future comparison of optimized VSI x86 compilers vs Linux compilers

[Arne Vajhøj]

On 8/3/2020 2:34 PM, onewingedshark at gmail.com wrote:
> On Friday, July 31, 2020 at 9:09:06 AM UTC-6, John Reagan wrote:
>> LLVM's optimizer relies on metadata called TBAA (Type-Based Alias
>> Analysis).  The LLVM IR and basic type system isn't sufficient to
>> describe all the different language rules for correct optimization
>> for any language.  For example, the clang frontend has to decorate
>> the LLVM IR with C/C++ language aliasing rules.
>> 
>> Our GEM-to-LLVM converter has to process CIL from multiple
>> frontends, make LLVM IR, and produce TBAA metadata.  Can we be as
>> good as clang for our C frontend?  What about Fortran, COBOL, etc.
>> On real GEM targets, there are callbacks between GEM and the
>> frontends so GEM can ask each frontend questions DURING
>> OPTIMIZATION.  That model doesn't exist in LLVM.  I'm hoping our
>> current design will get us within 90% of the best possible TBAA.
>> 
>> clang for C++ won't have this issue since it will be a clang
>> solution.  That's also one of the reasons why I want to also
>> provide the ability to invoke clang as a C compiler (at least for a
>> subset of C applications that don't use tons of VMS legacy junk -
>> I'm look at you /STAND=VAXC)
> 
> Here's a question: how hard would it be to simply [re]write the
> code-generator for the GEM-compilers to do VMS x86? Yes, I realize
> there's a lot of hype around LLVM, and it would be nice to get the
> optimizations, but this should be weighted against what you have
> now.

I think VSI strategically wants to get on LLVM.

Modern compilers are very complex pieces of software. And for
some languages they are relative fast evolving software.

Having VMS specific compilers will result on either compilers
falling behind or VSI bleed out of money to fund the work.

Hooking into an external toolchain like LLVM is the only
way VSI can afford uptodate compilers long term.

Arne