s390 support

[nickdesaulniers]

@arndb sent a lot of patches for 390 recently. I think there's no more build errors? If so, maybe there's a defconfig or certain machine we can start testing?

[nathanchance]

I just tried building this in our Docker image. After installing binutils-s390x-linux-gnu and applying @arndb's patches from the s390 tree on top of next-20190503:

$ git diff c263a4e990b7^..ce968f6012f6 | git apply
$ make -j16 ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- CC=clang-9 HOSTCC=clang-9 O=/out performance_defconfig bzImage

Build log

I don't know if I am holding wrong or what but the most glaring issues (can file separate issues for these if needed):

• -Waddress-of-packed-member isn't getting disabled properly (maybe something with cc-option as well because -fno-null-pointer-checks isn't being enabled either).

• Error in lib/raid6/s390vx8.c (maybe a binutils error?):

  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
          asm volatile ("VLM %2,%3,0,%r1"
                        ^
  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
  lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
  6 errors generated.
  

For CI, we'll need to get a proper set of QEMU flags and a rootfs going.

[arndb]

On Fri, May 3, 2019 at 10:39 PM Nathan Chancellor ***@***.***> wrote: I just tried building this in our Docker image. After installing binutils-s390x-linux-gnu and applying @arndb <https://github.com/arndb>'s patches from the s390 tree <https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/log/?h=features> on top of next-20190503: $ git diff c263a4e990b7^..ce968f6012f6 | git apply $ make -j16 ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- CC=clang-9 HOSTCC=clang-9 O=/out performance_defconfig bzImage Build log <https://gist.github.com/0eafed9755907f3bc6c35ca30fb19f18>

Note: building with "make -s" makes much more readable logs.

I don't know if I am holding wrong or what but the most glaring issues (can file separate issues for these if needed): - -Waddress-of-packed-member isn't getting disabled properly (maybe something with cc-option as well because -fno-null-pointer-checks isn't being enabled either).

Hmm, regardless of whether the logic to turn off the warning is correct, it seems to me that we shouldn't really turn off this one in particular, the warnings do seem to indicate actual bugs.

- - Error in lib/raid6/s390vx8.c (maybe a binutils error?): lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' asm volatile ("VLM %2,%3,0,%r1" ^ lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}' 6 errors generated. I don't remember seeingi this one. Which binutils version did you use?

Arnd

[nathanchance]

Note: building with "make -s" makes much more readable logs.

Copy.

Hmm, regardless of whether the logic to turn off the warning is correct, it seems to me that we shouldn't really turn off this one in particular, the warnings do seem to indicate actual bugs.

Note, this has been disabled for clang since https://git.kernel.org/linus/bfb38988c51e440fd7062ddf3157f7d8b1dd5d70 and Linus disabled it for the whole kernel a couple of days ago in https://git.kernel.org/linus/6f303d60534c46aa1a239f29c321f95c83dda748

I don't remember seeing this one. Which binutils version did you use?

root@89d434e76dca:/linux-next# s390x-linux-gnu-ld --version | head -n1
GNU ld (GNU Binutils for Debian) 2.31.1

I'll try tip of tree and Debian stable.

[nathanchance]

Turns out that error is an LLVM regression because the release/8.x branch is fine. I'll bisect tonight

[nathanchance]

As it turns out... cc @nickdesaulniers

git bisect start
# good: [7b5565418f4d6e113ba805dad40d471d23bca6f6] Fix build breakage from llvm r351317
git bisect good 7b5565418f4d6e113ba805dad40d471d23bca6f6
# bad: [1e393064fa2732e721524f95a12348b0fd981167] [Driver] Create non-existent directory for -fcrash-diagnostics-dir
git bisect bad 1e393064fa2732e721524f95a12348b0fd981167
# good: [d84f6059105fe400c60fcd5e64674adaf6190613] [ScalarizeMaskedMemIntrin] Only set the ModifiedDT flag if new basic blocks were added.
git bisect good d84f6059105fe400c60fcd5e64674adaf6190613
# good: [af1cbdd3bac09a280e026a78b13bc7f61f88faf0] Fix spelling mistake. NFCI.
git bisect good af1cbdd3bac09a280e026a78b13bc7f61f88faf0
# good: [01f8d556aa7274336f94afe6581bded378f3b4f4] [PGO/SamplePGO][NFC] Move the function updateProfWeight from Instruction to CallInst.
git bisect good 01f8d556aa7274336f94afe6581bded378f3b4f4
# bad: [01efe64c2d60e44bb035501205fa595f80028ca7] [clangd] Surface diagnostics from headers inside main file
git bisect bad 01efe64c2d60e44bb035501205fa595f80028ca7
# good: [733c8c40c81de5fcc8fab264ccb6bce6d39138c5] Enable LoopVectorization by default.
git bisect good 733c8c40c81de5fcc8fab264ccb6bce6d39138c5
# good: [c1da14941fb70a5c0995bd73d64b30e7e57acd2c] [yaml2obj] - Remove excessive variable. NFC.
git bisect good c1da14941fb70a5c0995bd73d64b30e7e57acd2c
# bad: [83c6d10b62a9575c19dfb0977ef675aeb996319a] [sanitizer] NFC: add static_assert to confirm that we use reasonable ByteMap type
git bisect bad 83c6d10b62a9575c19dfb0977ef675aeb996319a
# good: [27e01e675c1acd9f648847d96f296b611f22628f] [X86][AVX] Fold extract_subvector(broadcast(x)) -> broadcast(x) iff x has one use
git bisect good 27e01e675c1acd9f648847d96f296b611f22628f
# bad: [18b0c40bc5dbaf25157a838701b2aba8ba8440db] [AArch64] Add support for MTE intrinsics This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485
git bisect bad 18b0c40bc5dbaf25157a838701b2aba8ba8440db
# bad: [5ddc6d180cd660fa1b70e0c251a95b70ad743ac9] [OPENMP]Added check for non-random access types for the dependent loop counters.
git bisect bad 5ddc6d180cd660fa1b70e0c251a95b70ad743ac9
# good: [74967cb4e04c9899601b8c84901e99e797d49135] [Sanitizer] Fix test
git bisect good 74967cb4e04c9899601b8c84901e99e797d49135
# bad: [16b90733c751ccf80e2c6e31838dc6f1a4f3d38e] [ASTImporter] Copy Argument Passing Restrictions setting when importing a CXXRecordDecl definition
git bisect bad 16b90733c751ccf80e2c6e31838dc6f1a4f3d38e
# bad: [7ab164c4a427b559a7a47fa62ef365862705f950] [AsmPrinter] refactor to support %c w/ GlobalAddress'
git bisect bad 7ab164c4a427b559a7a47fa62ef365862705f950
# first bad commit: [7ab164c4a427b559a7a47fa62ef365862705f950] [AsmPrinter] refactor to support %c w/ GlobalAddress'

[nathanchance]

After reverting llvm/llvm-project@7ab164c, I can build performance_defconfig without any issues.

However, booting it in QEMU does not work. It seems that CONFIG_MARCH_Z900 is needed, according to @groeck's run-qemu-s390.sh, which was disabled by https://git.kernel.org/s390/linux/c/c263a4e990b7296b074e33aa077239a0a28a818e.

[nickdesaulniers]

lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
After reverting llvm/llvm-project@7ab164c, I can build performance_defconfig without any issues.

Haha, sorry! Thanks for bisecting. I didn't even touch %r in that patch, lol. PPCAsmPrinter::PrintAsmOperand doesn't handle %r, and neither does AsmPrinter::PrintAsmOperand, so I'm a bit perplexed on first look. I can dig into this further maybe next week.

[nickdesaulniers]

Looking through https://github.com/bminor/binutils-gdb/tree/master/gas/testsuite/gas/s390, it seems that %r[digit] is supposed to be a register, not an output template.

So if my patch has anything to do with interpreting %r as an output template, then I assume that means that inline asm for s390 is horribly broken in clang. (oh look, the test case I added in llvm/llvm-project@7ab164c is the only test for inline assembly in llvm/test/CodeGen/SystemZ/ 🆗 🆒 😎 )

[nathanchance]

Looks like the s390 guys are testing clang themselves?

https://git.kernel.org/linus/740eaf7d4dd255789987a543b0203ca239b37087

$ make -j$(nproc) -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- CC=clang-11 HOSTCC=clang-11 O=/out defconfig bzImage

works for me at https://git.kernel.org/linus/6992ca0dd017ebaa2bf8e9dcc49f1c3b7033b082