Part of the project to eliminate special handling for triples in lit
expressions.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The changes in this patch assume that there aren't any possible suffixes after the -zos part of the triple (no version numbers, like you might find with darwin or macos, and nothing like -elf or -eabi like some targets have). If there are suffixes, I'll happily revise to put {{.*}} after everything.
The one test I could not verify is llvm/test/Support/encoding.ll, because I don't have the utilities that it needs. But UNSUPPORTED: ! was the workaround for not having triples allowed in REQUIRES: so I think it's the right change.
I think for consistency with other targets, and to be safe for future extensions of the target triple, it would be better to add the {{.*}}
The one test I could not verify is llvm/test/Support/encoding.ll, because I don't have the utilities that it needs. But UNSUPPORTED: ! was the workaround for not having triples allowed in REQUIRES: so I think it's the right change.
The question here is, what are the specific requirements for the test to run. One part is that the test just calls plain llc but expects this will generate code appropriate for z/OS. That's not how this is usually done. Instead, you should add an explicit target triple to the llc invocation, e.g. llc -mtriple=s390x-ibm-zos. However, as this requires that support for the SystemZ target is built into LLVM, you then also need to add the following:
REQUIRES: systemz-registered-target
This has the advantage that the test will actually be run on any host platform, as long as the target support is built in (which is is by default e.g. in the CI builders).
However, it might also be the case that the test case requires a z/OS host environment to run on. I believe this is true here, since chtag seems to be a z/OS specific tool, and iconv (in particular when using the IBM-1047 code page) also may not be universally available.
To express that restriction on the *host* system, you should be using a REQUIRES: system-zos line. However, it looks like this capability is not actually currently implemented - you'll have to add it to the code in utils/lit/lit/llvm/config.py here:
[...] elif platform.system() == 'NetBSD': features.add('system-netbsd') elif platform.system() == 'AIX': features.add('system-aix') elif platform.system() == 'SunOS': features.add('system-solaris')
(Note that you probably still should add the -mtriple because the test case requires *both* running on a z/OS host *and* compiling for the z/OS target.)
Okay.
[for encoding.ll] To express that restriction on the *host* system, you should be using a REQUIRES: system-zos line. However, it looks like this capability is not actually currently implemented - you'll have to add it to the code in utils/lit/lit/llvm/config.py here:
[...] elif platform.system() == 'NetBSD': features.add('system-netbsd') elif platform.system() == 'AIX': features.add('system-aix') elif platform.system() == 'SunOS': features.add('system-solaris')(Note that you probably still should add the -mtriple because the test case requires *both* running on a z/OS host *and* compiling for the z/OS target.)
If you can tell me the platform.system() value to look for to detect z/OS, I can do that. Probably as a separate patch, as it would be going beyond the mechanical replacement that I'm doing for everything else.
Add trailing '{{.*}}' as requested.
Have not changed the encoding.ll test, waiting on @uweigand about correct value to test in Python.
I don't know - this value is defined by the Python implementation on z/OS. On most platforms, this matches the value returned by "uname -s", but I don't know what this is on z/OS either.
I suppose we could temporarily add a test that does
; REQUIRES: target={{.*}}-zos ; RUN: %python -c 'import platform; print(platform.system())' && false
and see what gets printed.
Searching the buildbot console page for 'zos' turns up nothing; 's390' turns up clang-s390x-linux, clang-s390x-linux-lnt, mlir-s390x-linux. Are there any zos hosted bots? I.e., is this test ever actually run? Maybe there are only downstream zos bots, in which case this should be a downstream test instead?
There will be suffixes after the -zos part. Thanks for adding the pattern at the end.
We are in the process of setting up a buildbot for z/OS. I would appreciate to have this upstream.