[LLVMdev] Introduction for new consumer of LLVM

[Robinson, Paul]

> > That includes BASIC, COBOL, Fortran, Pascal, C, BLISS (one of the
> > OpenVMS implementation languages), and Macro32 (a compiler that accepts
> > VAX assembly source code and emits object code for the appropriate target,
> > either Alpha or Itanium).  On Alpha and Itanium, we use our own multi-
> > language, retargetable backend called GEM.  Our strategy will be to write
> > a converter between the GEM IL and the LLVM IL.  We will first be hosting
> > the x86-target compilers as cross-compilers running on OpenVMS Itanium to
> > bootstrap the OS and eventually the compilers themselves onto a future
> > OpenVMS x86 platform. I suspect we will be contributing several
> > interesting enhancements as we go along. We also intend to provide clang
> > as well for our C++ offering.
> 
> Do you have any plans to resurrect the LLVM Alpha and Itanium back ends,
> to reduce the variation in compiler output across your platforms?  I
> imagine that doing GEM optimisations and then generating native code, vs
> doing GEM optimisations and then generating LLVM IR, doing LLVM
> optimisations, and then generate native code will give quite different
> performance characteristics (and very different interpretations of
> undefined behaviour).

I have no special insight into VMSSoftware's plans in general or John's
in particular, but as a former DEC and HP employee I think it's safe to
say that the risk of adopting new compiler technology for *existing*
platforms is too high for sensitive corporate nervous systems to take.
And that "new" technology consists of resurrecting some pretty old
backends (they were removed in what, LLVM 3.0?).  Not saying it could
never happen, but stability of existing platforms is very important in
the enterprise space.
--paulr

> 
> Also, I wondered if you'd considered (assuming that you are legally able
> to) open sourcing your Fortran front end.  There are a number of LLVM
> consumers who are interested in a high-quality Fortran front end for LLVM
> and several efforts in this direction.  There are probably some people
> interested in COBOL too, though that's a somewhat terrifying thought.
> 
> For COBOL, I suspect that you will run into limitations with LLVM's (lack
> of) support for decimal floating point.  This is also theoretically a
> limitation for the C front end, but I don't actually know of any real-
> world C code that uses decimal floats.
> 
> David
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev