
IBM to transition z/OS, Power and AIX Compilers to being LLVM/Clang-based - rbanffy
https://www.phoronix.com/scan.php?page=news_item&px=IBM-Will-Use-LLVM-Clang-Stack
======
apaprocki
This has been in progress for a while now. XL 16.1 integrated in the Clang
front-end (as xlclang/xlclang++) and was available to play with around the
beginning of 2019. In early 2019 IBM had already started working on building
out the support for writing XCOFF binaries in LLVM as ground work to move the
back-end over. I got the front-end working on AIX in ~2016 so that libclang
could be used for tooling, but the upstream patch lingered until IBM picked up
the work in Feb 2019 and started really building it out.

Tangentially, Oracle did something similar but instead adopted GCC’s front-end
for their compiler.

What’s unclear for both is how they will modify the compiler release cycles to
accommodate the upstream LLVM (& GCC) release cycles so they don’t linger too
long on old code. IIRC XL 16.1 xlclang was based around a snapshot of Clang
4.x , which is not great when we’re now on the eve of Clang 10.

------
jabl
One wonders whether this is a

\- cost cutting measure. Maintain the zOS and AIX/POWER backends, kick the
rest of the XL compilers teams.

or

\- Advance the state of the art in compilers, by avoiding as much wheel
reinvention as before.

~~~
apaprocki
A mix of both? It seemed obvious by C++11 completion in GCC/Clang that
achieving later standards in the vendor compiler front-end implementations
would be a huge investment of time with diminishing returns. Since the C++
committee adopted the planned 3 year release cycle, that kind of sealed their
fate (IMO). It was much easier to coast when there was an 8-year hiatus
between standards (03 to 11) in the “modern” C++/Linux age.

~~~
chungus_khan
It's a lot like web tech and browsers. It used to be a much more manageable
effort to create an entirely new browser engine, but now that the standard is
larger and faster moving, smaller entrants haven't been able to keep up. It's
an interesting consequence of these faster moving targets that they trend
towards consolidation down to two competing entrants in both cases.

~~~
PaulHoule
That was 1995 when a "new browser engine" was easy. Not long, however, open
source web browsers developed a bad reputation.

Back then one reason was that 40% or so of all web pages had broken HTML (e.g.
<tag) but that Netscape rendered them anyway. To make a usable web browser you
needed to render broken HTML the same way Netscape did, which was
undocumented.

~~~
erichocean
Sure, but that specific issue has been resolved 100% AFAIK with the HTML 5
parsing algorithm being fully specified now.

~~~
PaulHoule
That's right.

Overall the HTML 5 specification represents a huge step in specificity over
other specs in the industry.

On the other hand if you want to make a modern web browser now you need a very
fast Javascript engine and a highly complex rendering engine...

------
exabrial
My understanding of GCC vs Clang/LLVM is GCC generally produces faster code,
but Clang over LLVM offers a richer feature set and more organized code base.
Is this correct?

~~~
adrianmonk
In many cases, GCC and LLVM/Clang are the two alternatives.

But in this case, I believe we are talking about IBM's XL compilers. These are
proprietary compilers written by IBM.

See
[https://en.wikipedia.org/wiki/IBM_XL_C/C%2B%2B_Compilers](https://en.wikipedia.org/wiki/IBM_XL_C/C%2B%2B_Compilers)

IBM has been offering proprietary compilers for operating systems like AIX for
quite a long time. Going back to the mid-90s in my personal experience, and
probably going back further than that too.

~~~
exabrial
Ah thank you! I knew someone would have the answer

------
pdpi
"IBM uses Apple's compiler infrastructure for their big iron" is such a weird
statement to make. Of all the open source projects Apple has sponsored, Clang
and (especially) LLVM have to be the most impactful.

~~~
wyldfire
It's not accurate to call it "Apple's compiler infrastructure" IMO. They're
one of several commercial sponsors/contributors.

~~~
pdpi
Apple hired Chris Lattner and built a team around him to work on LLVM, and
have built it into the core of macOS (as a JIT for GPU code), and they started
the Clang project. Clang/LLVM is the default C/C++ compiler for macOS (versus
VCC in Windows and GCC in Linux).

The project is not _technically_ owned by Apple, but they are still the
highest tier sponsors for the project, and are the one org with the most
history with it. I don't think calling it "Apple's compiler infrastructure" is
that unreasonable

~~~
Joky
The fact that Apple basically bootstrapped the project 10 years ago does not
mean it is forever “Apple’s compiler”. The community is much much larger than
any single vendor out there.

------
zengid
<fantasize> it would be neat if that upstream contribution for their back end
would let them support other LLVM generated languages natively, like Julia or
Rust. Much better than COBOL! </fantasize>

~~~
apaprocki
I don’t see how it could stop that from happening unless some front-end
language requires features that the binary format or platform just can’t
support. The fact that they are going to support Clang/Flang already shows
that to be the case.

