Re: VSI compiler webinar

On 3/24/2025 2:41 PM, Simon Clubley wrote:

On 2025-03-23, Arne Vajhøj <arne@vajhoej.dk> wrote:

>
But VMS LLVM is rather old (if I remember correctly then it
is, because it had to be build on Itanium with VMS C++
for cross compilers).
>

 You also need CMake to build current LLVM versions. John was working
on this at one time, but I don't know what the current status is.
 Simon.
 

Lots of good questions for sure!  And be sure to come see me in person in May in Malmö at the VSI Bootcamp.  I'll be on display daily.
Yes, we are currently using clang/LLVM 10.0.1.  It is bootstrapped using a Linux version of the same code base with changes to create OpenVMS objects (it knows about CRTL name mapping, argcounts, and all that stuff).  What we did was:
- start with the plain 10.0.1 sources and 10.0.1 binaries
- add code to clang/LLVM (much of the LLVM changes were just carried over from the LLVM 3.4.2 codebase we used with the cross compilers)
- build that code on Linux creating a 10.0.1v compiler
- use that compiler to build it all again
- copy all the .o files over to an OpenVMS machine to put into OLBs
- link clang using those OLBs on OpenVMS
- use that clang on OpenVMS to build our G2L (GEM to LLVM converter)
- link all the legacy frontends (originally build with cross compilers but now built with native compilers) with the G2L and LLVM libraries
- test & make kits
- and Bob's your uncle and much easier than learning to say the French R sound
As for native building, we do have a CMake ported and are currently working on native building that 10.0.1v source tree on OpenVMS V9.2-3 including some work to CMake to make it easier for symbol vector management for LIBCXX/LIBCXXABI.  Not quite to testing yet.
We have also downloaded the latest LLVM (either 20.1.0 or 20.1.1, I'd have to go check).  As a first step, we've been able to compile that on Linux using the same 10.0.1v compiler that we use today.  The LLVM 20 code base is much larger as you can imagine and we're working on linking up the LIBCXX/LIBCXXABI libraries right now.  The number of LLVM libraries is also different.  We've merged in some but not all of the OpenVMS additions but nothing tested yet.  We'll have to upgrade our G2L since the internal LLVM IR is not guaranteed to be upward compatible and they've changed several of the interfaces over the last few years.  And to make it even more painful, LLVM 20 now requires a newer CMake version than the one we ported.  Ugh!  We'll do it again and then look at providing it online as well.
As for merging our code back into the actually LLVM repo, that's still a work in progress.  Once we switch to LLVM 20, we will be in a much better position to make the case to the LLVM community.  I think it will be an easier discussion for the LLVM changes.  The clang changes might be a tougher sell since our addition of dual-sized pointers, listing files, etc might scare off a few people. It would be difficult for the build bots to build (we would have to provide and manage some systems).
Making our VSI git repositories visible would be another choice. However, if you haven't noticed,
https://arstechnica.com/gadgets/2025/03/google-makes-android-development-private-will-continue-open-source-releases/
Besides the sources (and scripts), I'd like to make another kit of pre-built images (and perhaps the LLVM libraries) that come out of the LLVM build today.  There are some of the LLVM tools that are only useful to compiler developers like llvm-dis but there are some tools like clang-format, llvm-objdump, llvm-dwarfdump, llvm-nm, etc that others might want.  For example, the X86ASM product on the support portal is just the llvm-mc tool.  llvm-mc is quite powerful as both an assembler AND disassembler.  It can even convert between AMD and Intel syntax as a party trick.
G2L, while completely written by VSI, would only be useful if you have a compiler frontend that generates GEM CIL.  And G2L does use GEM headers so that's where the existing HPE copyrights start to appear.
Vi ses snart i Malmö