This is an archive of the discontinued LLVM Phabricator instance.

[ZOS] Convert tests to check 'target={{.*}}-zos'
ClosedPublic

Authored by probinson on Dec 6 2022, 10:37 AM.

Details

Summary

Part of the project to eliminate special handling for triples in lit
expressions.

Diff Detail

Event Timeline

probinson created this revision.Dec 6 2022, 10:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 6 2022, 10:37 AM
probinson requested review of this revision.Dec 6 2022, 10:37 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptDec 6 2022, 10:37 AM

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.

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.

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.)

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.

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 {{.*}}

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.

probinson updated this revision to Diff 481421.Dec 8 2022, 12:57 PM

Add trailing '{{.*}}' as requested.
Have not changed the encoding.ll test, waiting on @uweigand about correct value to test in Python.

If you can tell me the platform.system() value to look for to detect z/OS, I can do that.

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.

If you can tell me the platform.system() value to look for to detect z/OS, I can do that.

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.

@Kai - maybe you can help with this.

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?

Kai added a comment.Dec 12 2022, 9:54 AM

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.

On z/OS, platform.system() returns OS/390.

Kai added a comment.Dec 12 2022, 9:56 AM

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.

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 {{.*}}

There will be suffixes after the -zos part. Thanks for adding the pattern at the end.

Kai added a comment.Dec 12 2022, 9:59 AM

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?

We are in the process of setting up a buildbot for z/OS. I would appreciate to have this upstream.

Define 'system-zos' and use it in the one test that needs it.

Thanks @Kai and @uweigand, good to know a z/OS bot is in the works. Hope this patch now meets your needs.

uweigand accepted this revision.Dec 12 2022, 10:43 AM

LGTM, thanks!

This revision is now accepted and ready to land.Dec 12 2022, 10:43 AM
This revision was landed with ongoing or failed builds.Dec 12 2022, 11:25 AM
This revision was automatically updated to reflect the committed changes.