Expensive checks AArch64 builder

Project Infrastructure
1

When I build with expensive checks enabled and run check-all on AArch64 I am getting the following errors:

  Failed Tests (3):
  LLVM :: CodeGen/Generic/2010-11-04-BigByval.ll
  LLVM-Unit :: IR/./IRTests/BasicBlockTest/SpliceEndBeforeBegin
  LLVM-Unit :: IR/./IRTests/FunctionTest/SpliceEndBeforeBegin

From a quick look, they look genuine problems to me.

But the other thing that this highlights is that we don’t have an AArch64 builder with expensive checks enabled? Would it be worth having that?

CC: @DavidSpickett as you might have some experience/opinions on this?

2

I dug into some of these a while ago. I can take a look.

Can you confirm the situation first. You’re enabling expensive checks locally, correct? Rather than seeing this on a buildbot (builder is the term it uses), afaik we don’t have an expensive checks builder for AArch64.

If it turns out to be AArch64 specific maybe a bot is worth it, but likely I’ll just be wondering why they weren’t caught elsewhere.

Also, are you building against libcxx or libstdc++? Sometimes these failures are caused by the checks enabled in the hardened/debug modes of these libraries.

3

Thanks for your speedy reply!

Yes, that’s right, I am doing this locally. After that I was basically just having the same questions and wondering why we don’t catch this with the upstream bots.

The regression test might be related to AArch64 frame lowering, which would explain why the upstream bots don’t catch this; from a quick look, we only have X86 expensive check bots.
The IRTests failures don’t mean much to me, don’t know what’s going on there.

I am not specifying to use libcxx, so I guess that means I am using libstdc++.

4

I only got LLVM :: CodeGen/Generic/2010-11-04-BigByval.ll failing, but it’s possible that using GCC to build avoids the other 2.

Anyway this one looks legit:

bb.0 (%ir-block.0):
  ADJCALLSTACKDOWN 131072, 0, implicit-def dead $sp, implicit $sp
  ADJCALLSTACKDOWN 0, 0, implicit-def dead $sp, implicit $sp
  %0:gpr64all = COPY $sp
  %1:gpr32 = MOVi32imm 131072
  %2:gpr64all = SUBREG_TO_REG 0, killed %1:gpr32, %subreg.sub_32
  %3:gpr64sp = ADDXri %fixed-stack.0, 0, 0
  $x0 = COPY %0:gpr64all
  $x1 = COPY %3:gpr64sp
  $x2 = COPY %2:gpr64all
  BL &memcpy, <regmask $fp $lr $wzr $xzr $b8 $b9 $b10 $b11 $b12 $b13 $b14 $b15 $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $h8 $h9 $h10 $h11 $h12 $h13 $h14 $h15 $s8 $s9 $s10 $s11 $s12 and 55 more...>, implicit-def dead $lr, implicit $sp, implicit $x0, implicit $x1, implicit $x2, implicit-def $sp, implicit-def $x0
  ADJCALLSTACKUP 0, 0, implicit-def dead $sp, implicit $sp
  %4:gpr64all = COPY $x0
  BL @foo, <regmask $fp $lr $wzr $xzr $b8 $b9 $b10 $b11 $b12 $b13 $b14 $b15 $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $h8 $h9 $h10 $h11 $h12 $h13 $h14 $h15 $s8 $s9 $s10 $s11 $s12 and 55 more...>, implicit-def dead $lr, implicit $sp, implicit-def $sp
  ADJCALLSTACKUP 131072, 0, implicit-def dead $sp, implicit $sp
  RET_ReallyLR

# End machine code for function bar.

*** Bad machine code: FrameSetup is after another FrameSetup ***
- function:    bar
- basic block: %bb.0  (0xaaaaf32a3288)
- instruction: ADJCALLSTACKDOWN 0, 0, implicit-def dead $sp, implicit $sp

*** Bad machine code: FrameDestroy <n> is after FrameSetup <m> ***
- function:    bar
- basic block: %bb.0  (0xaaaaf32a3288)
- instruction: ADJCALLSTACKUP 0, 0, implicit-def dead $sp, implicit $sp
FrameDestroy <0> is after FrameSetup <131072>.

*** Bad machine code: FrameDestroy is not after a FrameSetup ***
- function:    bar
- basic block: %bb.0  (0xaaaaf32a3288)
- instruction: ADJCALLSTACKUP 131072, 0, implicit-def dead $sp, implicit $sp
LLVM ERROR: Found 3 machine code errors.

First time seeing any of that but I think it’s adjusting the current stack, not resetting it. Using 0, 0 means the end result isn’t wrong, but perhaps we expected that to have been removed by this stage?

5

Agreed, that looks legit. I think we have 2 issues going on here.

The first is this failing regression tests (let’s ignore the unit tests for now) for which we should raise an GH issue. I might be able to look at it and work on it on the side, but can’t promise it yet.

The second issue here is that we don’t catch this upstream. I don’t know what the costs would be to add an expensive checker for AArch64 and if it’s worth it.

6

I’ll think about a bot. Might be able to add expensive checks to an existing one.

7

I’ll think about a bot. Might be able to add expensive checks to an existing one.

Thanks, please let me know what you will do, and let me know if I can help.