[RFC/PATCH][0/4] New SystemZ backend

Hello,

I'd like to propose the addition of a new SystemZ backend to the LLVM and
Clang code base. We're interested in this for the same reason we've been
interested in the PowerPC back-end recently: to enable packages in upcoming
enterprise Linux distributions that need LLVM support (e.g. 3D desktop
support via llvmpipe).

Now, I understand that a SystemZ backend used to be part of LLVM for a
while, but has been removed (due to lack of maintenance, it would appear).
While the backend provided by this set of patches is originally based on
that old SystemZ backend, it has been significantly rewritten and many of
the missing "modern" features added.

At this stage, we've chosen to limit the feature set to the following:
- 64-bit z/Architecture only (same as the old backend)
- support for z10 (and newer) processor only (old backend supported z9)
- Linux operating system support only (same as the old backend)
- focus on feature completeness and correctness, not performance (no
platform-specific optimizations have been implemented yet)

Given this set of limitations, the current status is
- Working C/C++ compiler
  * Passes internal testsuite and projects/test-suite with no failures
  * Passes a full bootstrap with identical stage2/stage3 results
  * Builds and runs SPECcpu2006 benchmarks successfully
  * Passes the ABI compatibility test suite against GCC 4.8
- Working integrated assembler
  * Passes both testsuites with integrated assembler forced on
- Working assembler parser
  * Passes both testsuites when using clang assembler instead of system
assembler
- Working MCJIT (no support for old JIT)
  * Passes JIT testsuite

The actual patches are appended to subsequent mails, cross-posted to
llvm-commits and cfe-commits as appropriate:
- LLVM code changes
- LLVM testsuite changes
- Clang changes
- Changes to support SystemZ as host

Note that the patches were primarily developed by Richard Sandiford (on
CC). He had planned to post them for submission himself, but he's on
vacation for several weeks right now, and given the short timeline until
the 3.3 release branches, we decided that I should post the patches now to
get the discussion started ...

I'd appreciate any comments and/or review!

Bye,
Ulrich

I'd like to propose the addition of a new SystemZ backend to the LLVM and
Clang code base. We're interested in this for the same reason we've been
interested in the PowerPC back-end recently: to enable packages in upcoming
enterprise Linux distributions that need LLVM support (e.g. 3D desktop
support via llvmpipe).

Cool!

- focus on feature completeness and correctness, not performance (no
platform-specific optimizations have been implemented yet)

My understanding is that the most important things here are:
1. Precise flags tracking & using (LLVM is not so good at this)
2. Good scheduling (are recent z10's still in-order?)

> I'd like to propose the addition of a new SystemZ backend to the LLVM

and

> Clang code base. We're interested in this for the same reason we've

been

> interested in the PowerPC back-end recently: to enable packages in

upcoming

> enterprise Linux distributions that need LLVM support (e.g. 3D desktop
> support via llvmpipe).
Cool!

> - focus on feature completeness and correctness, not performance (no
> platform-specific optimizations have been implemented yet)

Note that we *are* planning on working on this in the future, it's just
something we chose to skip for the first patch ... B.t.w. even with
the patch as-is, we're only about 15% worse than current GCC on
SPECcpu2006 overall, so while there's clearly still room for improvement,
it's not really bad either.

My understanding is that the most important things here are:
1. Precise flags tracking & using (LLVM is not so good at this)

Indeed. This has proven to be quite important for the GCC
back-end too (back in the day ... :-)).

2. Good scheduling (are recent z10's still in-order?)

z10 is in-order, so scheduling is important (maybe moreso
than on z9). z196 is now out-of-order, but still scheduling
for the instruction grouping logic seems to help with GCC ...

In addition, we also want to (optionally) support new z196
instructions.

Bye,
Ulrich