27481 – X86 make check has a bunch of machine verifier errors

LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 27481 - X86 make check has a bunch of machine verifier errors

Summary: X86 make check has a bunch of machine verifier errors

Status:	RESOLVED FIXED

Alias:	None

Product:	libraries
Classification:	Unclassified
Component:	Backend: X86 (show other bugs)
Version:	trunk
Hardware:	PC All

Importance:	P normal
Assignee:	Unassigned LLVM Bugs

URL:
Keywords:

Depends on:	39436 39437 39439 39440 39451 39452 21903 33028 38147 38150 38376 38391 39481
Blocks:	32146
	Show dependency tree

Reported:	2016-04-22 13:16 PDT by Quentin Colombet
Modified:	2019-09-06 16:44 PDT (History)
CC List:	11 users (show)

See Also:	30998 34720
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Quentin Colombet 2016-04-22 13:16:13 PDT

Switching the machine verifier ON by default (lib/CodeGen/Passes.cpp then change the default value of the cl::opt related to the machine verifier) leads to a bunch of machine verifier errors for make check:
    LLVM :: CodeGen/X86/cleanuppad-inalloca.ll
    LLVM :: CodeGen/X86/cmpxchg-clobber-flags.ll
    LLVM :: CodeGen/X86/cxx_tlscc64.ll
    LLVM :: CodeGen/X86/darwin-tls.ll
    LLVM :: CodeGen/X86/fast-isel-nontemporal.ll
    LLVM :: CodeGen/X86/i386-tlscall-fastregalloc.ll
    LLVM :: CodeGen/X86/implicit-null-check.ll
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/inalloca-invoke.ll
    LLVM :: CodeGen/X86/inalloca-regparm.ll
    LLVM :: CodeGen/X86/inalloca-stdcall.ll
    LLVM :: CodeGen/X86/inalloca.ll
    LLVM :: CodeGen/X86/machine-sink-and-implicit-null-checks.ll
    LLVM :: CodeGen/X86/musttail-indirect.ll
    LLVM :: CodeGen/X86/musttail-thiscall.ll
    LLVM :: CodeGen/X86/musttail-varargs.ll
    LLVM :: CodeGen/X86/peephole-na-phys-copy-folding.ll
    LLVM :: CodeGen/X86/pku.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shrink-wrap-chkstk.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/stack-folding-fp-avx1.ll
    LLVM :: CodeGen/X86/stack-folding-fp-sse42.ll
    LLVM :: CodeGen/X86/tls-models.ll
    LLVM :: CodeGen/X86/tlv-1.ll
    LLVM :: CodeGen/X86/tlv-2.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/x32-function_pointer-1.ll
    LLVM :: CodeGen/X86/x86-64-stack-and-frame-ptr.ll
    LLVM :: CodeGen/X86/x86-interrupt_vzeroupper.ll
    LLVM :: CodeGen/X86/x86-shrink-wrapping.ll

This may be latent bugs.

Comment 1 Quentin Colombet 2016-04-22 17:14:02 PDT

CodeGen/X86/cleanuppad-inalloca.ll is a fun one. The inalloca attribute says that the callee will make the alloca, but the caller will clean it.
We end up with the machine verifier complaining about a destroy frame before a setup frame and there is currently no way to tell the verifier that those bits are actually allocated by the callee. I think the proper fix is to add to the stackadjust down instruction an argument with the number of bytes that are push by the callee, similar to what we do with stackadjust up and the number of bytes pop by the callee.

That would take a bit of effort because currently the only requirement for the frame setup and frame destroy instructions is to haveone immediate operand. Thus, we need to update all the backends and lowering to make this two.

Comment 2 Quentin Colombet 2016-04-26 18:25:55 PDT

Fix test/CodeGen/X86/cmpxchg-clobber-flags.ll in r267623. (+ some preparatory patches in r267621 and r267622.)
We now generate better code, because we do not try to push/pop RAX if it is not live.

The problem was that we were saving a dead register and the verifier requires to have an undef flag to mark that we know we are reading an undef value.

Comment 3 Quentin Colombet 2016-04-27 16:39:53 PDT

Fixed CodeGen/X86/cxx_tlscc64.ll in r267797. We need to glue the callseq_end to the tlscall, otherwise the target independent code sets a dead flag on the result register whereas it is not dead. Indeed, the target independent code walks the chain of glue to find the users of physical registers.

Comment 4 Quentin Colombet 2016-04-27 17:34:20 PDT

Fixed CodeGen/X86/fast-isel-nontemporal.ll in r267806.

We were using the wrong register class for source of the non-temporal store: FR32 instead of FR128. This did not cause any problem because contain the same registers behind the scene.

Comment 5 Quentin Colombet 2016-05-02 18:03:28 PDT

Partially fixed test/CodeGen/X86/implicit-null-check.ll in r267817 and r268327.

The problems were respectively that we were missing to update the liveness properply and that we failed to mark FAULTING_LOAD_OP as potential branch instructions.

We still have machine verifier failures on that tests though.

Comment 6 Quentin Colombet 2016-05-03 13:11:26 PDT

Fixed the final problem with implicit-null-cheks.ll in r268412. When I fixed the liveness update, I did not take into account that load instructions might have implicit-defs as well.

Comment 7 Quentin Colombet 2016-05-09 19:45:40 PDT

Fixed x86-interrupt_vzeroupper.ll in r268983. This one was pretty bad because we basically ended up having the AVX512 registers as callee saved registers whereas the target was not using AVX512!!

Comment 8 Simon Pilgrim 2016-05-10 05:09:49 PDT

(In reply to comment #7)
> Fixed x86-interrupt_vzeroupper.ll in r268983. This one was pretty bad
> because we basically ended up having the AVX512 registers as callee saved
> registers whereas the target was not using AVX512!!

I think this fixes PR26409 as well?

Comment 9 Quentin Colombet 2016-05-10 11:17:02 PDT

(In reply to comment #8)
> (In reply to comment #7)
> > Fixed x86-interrupt_vzeroupper.ll in r268983. This one was pretty bad
> > because we basically ended up having the AVX512 registers as callee saved
> > registers whereas the target was not using AVX512!!
> 
> I think this fixes PR26409 as well?

That may indeed be the case.
Could you double check, please?

Comment 10 Quentin Colombet 2016-05-10 19:36:10 PDT

Here is where we are now:
Failing Tests (10):
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/pku.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/stack-folding-fp-avx1.ll
    LLVM :: CodeGen/X86/stack-folding-fp-sse42.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll

(Plus the inalloca tests that I analyzed previously but did not fix.)

Comment 11 Simon Pilgrim 2016-08-08 13:02:06 PDT

(In reply to comment #10)
>     LLVM :: CodeGen/X86/stack-folding-fp-avx1.ll
>     LLVM :: CodeGen/X86/stack-folding-fp-sse42.ll

A candidate fix for these is at: https://reviews.llvm.org/D23276

Comment 12 Simon Pilgrim 2016-08-09 05:11:24 PDT

The stack folding tests are now fixed. The remaining issues are:

Failing Tests (16):
    LLVM :: CodeGen/X86/cleanuppad-inalloca.ll
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/inalloca-invoke.ll
    LLVM :: CodeGen/X86/inalloca-regparm.ll
    LLVM :: CodeGen/X86/inalloca-stdcall.ll
    LLVM :: CodeGen/X86/inalloca.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/musttail-indirect.ll
    LLVM :: CodeGen/X86/musttail-thiscall.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shrink-wrap-chkstk.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll

Comment 13 Simon Pilgrim 2016-11-12 15:48:16 PST

Current failing tests:

    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/cleanuppad-inalloca.ll
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/inalloca-invoke.ll
    LLVM :: CodeGen/X86/inalloca-regparm.ll
    LLVM :: CodeGen/X86/inalloca-stdcall.ll
    LLVM :: CodeGen/X86/inalloca.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/musttail-indirect.ll
    LLVM :: CodeGen/X86/musttail-thiscall.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shrink-wrap-chkstk.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/sse-regcall.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir

Comment 14 Simon Pilgrim 2017-03-21 12:29:05 PDT

Failing Tests (19):
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/cleanuppad-inalloca.ll
    LLVM :: CodeGen/X86/fast-isel-select-sse.ll
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/inalloca-invoke.ll
    LLVM :: CodeGen/X86/inalloca-regparm.ll
    LLVM :: CodeGen/X86/inalloca-stdcall.ll
    LLVM :: CodeGen/X86/inalloca.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/musttail-indirect.ll
    LLVM :: CodeGen/X86/musttail-thiscall.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shrink-wrap-chkstk.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir

Comment 15 Simon Pilgrim 2017-03-21 12:30:23 PDT

> LLVM :: CodeGen/X86/fast-isel-select-sse.ll

Candidate Fix: https://reviews.llvm.org/D31200

Comment 16 Simon Pilgrim 2017-03-26 06:08:22 PDT

Fixed fast-isel-select-sse.ll by rL298805.

Failing Tests (18):
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/cleanuppad-inalloca.ll
    LLVM :: CodeGen/X86/inalloca-ctor.ll
    LLVM :: CodeGen/X86/inalloca-invoke.ll
    LLVM :: CodeGen/X86/inalloca-regparm.ll
    LLVM :: CodeGen/X86/inalloca-stdcall.ll
    LLVM :: CodeGen/X86/inalloca.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/musttail-indirect.ll
    LLVM :: CodeGen/X86/musttail-thiscall.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shrink-wrap-chkstk.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir

Comment 17 Quentin Colombet 2017-05-01 10:28:37 PDT

For the inalloca tests, we have a candidate fix by Serge Pavlov:
https://reviews.llvm.org/D32394

Reviewers needed!

Comment 18 Simon Pilgrim 2017-05-09 10:06:06 PDT

Serge's alloca fix landed at rL302527.

Failing Tests (9):
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/rtm.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir

Comment 19 Simon Pilgrim 2017-05-20 14:27:56 PDT

CC'ing Igor as he added the GlobalISel tests recently

Current failing tests:
    LLVM :: CodeGen/X86/GlobalISel/ext.ll
    LLVM :: CodeGen/X86/GlobalISel/select-trunc.mir
    LLVM :: CodeGen/X86/GlobalISel/trunc.ll
    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir
    LLVM :: DebugInfo/MIR/X86/bit-piece-dh.mir

Comment 20 Igor Breger 2017-05-21 06:58:50 PDT

GlobalISel tests fixed in r303502.
Thanks for pointing it out to me!

Comment 21 Simon Pilgrim 2017-05-21 08:47:16 PDT

Thanks Igor.

Failing tests:

    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir
    LLVM :: DebugInfo/MIR/X86/bit-piece-dh.mir

Comment 22 Matthias Braun 2017-05-31 11:54:59 PDT

r304320 enabled the machine verifier by default with EXPENSIVE_CHECKS. X86 is one of the targets excluded from this by overriding TargetMachine::isMachineVerifierClean() to return false.

Please remove the override when the target at least passes all lit tests without machine verifier failure.

Comment 23 Simon Pilgrim 2017-09-06 10:10:48 PDT

Updated list, as it's been a while:

Failing Tests (14):
    LLVM :: CodeGen/Generic/zero-probability.mir
    LLVM :: CodeGen/MIR/X86/diexpr-win32.mir
    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: CodeGen/X86/xray-multiplerets-in-blocks.mir
    LLVM :: DebugInfo/MIR/X86/bit-piece-dh.mir
    LLVM :: DebugInfo/MIR/X86/empty-inline.mir

Comment 24 Simon Pilgrim 2018-07-13 05:00:55 PDT

Failing Tests (24):
    LLVM :: CodeGen/Generic/zero-probability.mir
    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/O3-pipeline.ll
    LLVM :: CodeGen/X86/PR37310.mir
    LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll
    LLVM :: CodeGen/X86/branch_instruction_and_target_split_perf_nops.mir
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/fentry-insertion.ll
    LLVM :: CodeGen/X86/icall-branch-funnel.ll
    LLVM :: CodeGen/X86/indirect-branch-tracking.ll
    LLVM :: CodeGen/X86/local_stack_symbol_ordering.ll
    LLVM :: CodeGen/X86/machine-outliner-disubprogram.ll
    LLVM :: CodeGen/X86/machine-outliner-tailcalls.ll
    LLVM :: CodeGen/X86/patchable-prologue.ll
    LLVM :: CodeGen/X86/retpoline-regparm.ll
    LLVM :: CodeGen/X86/retpoline.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/shadow-stack.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: DebugInfo/Generic/linear-dbg-value.ll
    LLVM :: DebugInfo/X86/live-debug-vars-discard-invalid.mir

Comment 25 Simon Pilgrim 2018-07-13 05:03:54 PDT

@jpaquette Any idea whats behind the machine outliner test failures?

e.g.
CodeGen\X86\machine-outliner-disubprogram.ll

# After Machine Outliner
# Machine code for function f1: NoPHIs, TracksLiveness, NoVRegs
Frame Objects:
  fi#-1: size=8, align=16, fixed, at location [SP-8]
  fi#0: size=4, align=4, at location [SP-12]
  fi#1: size=4, align=4, at location [SP-20]
  fi#2: size=4, align=4, at location [SP-16]

bb.0.entry:
  frame-setup PUSH64r killed $rbp, implicit-def $rsp, implicit $rsp
  CFI_INSTRUCTION def_cfa_offset 16
  CFI_INSTRUCTION offset $rbp, -16
  $rbp = frame-setup MOV64rr $rsp
  CFI_INSTRUCTION def_cfa_register $rbp
  $rsp = frame-setup SUB64ri8 $rsp, 12, implicit-def dead $eflags
  CALL64pcrel32 @OUTLINED_FUNCTION_1, implicit $rsp, implicit $ssp
  $rsp = frame-destroy ADD64ri8 $rsp, 12, implicit-def dead $eflags, debug-location !46; test.c:26:3
  $rbp = frame-destroy POP64r implicit-def $rsp, implicit $rsp, debug-location !46; test.c:26:3
  RETQ implicit $eax, debug-location !46; test.c:26:3

# End machine code for function f1.

*** Bad machine code: Using an undefined physical register ***
- function:    f1
- basic block: %bb.0 entry (0x1b5eec123b8)
- instruction: RETQ implicit $eax, debug-location !46; test.c:26:3
- operand 0:   implicit $eax
LLVM ERROR: Found 1 machine code errors.

error: command failed with exit status: 1

Comment 26 Francis Visoiu Mistrih 2018-07-13 07:46:53 PDT

Possible fix: https://reviews.llvm.org/D49295

Comment 27 Francis Visoiu Mistrih 2018-07-13 08:27:20 PDT

Possible fix for the tail call outliner issue as well: https://reviews.llvm.org/D49299

Comment 28 Jessica Paquette 2018-07-13 09:02:18 PDT

I think Francis' fixes should resolve the outliner failures once he lands them.

Comment 29 Simon Pilgrim 2018-09-27 11:08:09 PDT

Failing Tests (28):
    LLVM :: CodeGen/Generic/zero-probability.mir
    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/O3-pipeline.ll
    LLVM :: CodeGen/X86/PR37310.mir
    LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll
    LLVM :: CodeGen/X86/branch_instruction_and_target_split_perf_nops.mir
    LLVM :: CodeGen/X86/branchfolding-undef.mir
    LLVM :: CodeGen/X86/code-model-elf-memset.ll
    LLVM :: CodeGen/X86/code-model-elf.ll
    LLVM :: CodeGen/X86/fentry-insertion.ll
    LLVM :: CodeGen/X86/icall-branch-funnel.ll
    LLVM :: CodeGen/X86/indirect-branch-tracking.ll
    LLVM :: CodeGen/X86/large-pic-string.ll
    LLVM :: CodeGen/X86/patchable-prologue.ll
    LLVM :: CodeGen/X86/pr38795.ll
    LLVM :: CodeGen/X86/retpoline-regparm.ll
    LLVM :: CodeGen/X86/retpoline.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sibcall-2.ll
    LLVM :: CodeGen/X86/sibcall.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/speculative-load-hardening-indirect.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll
    LLVM :: DebugInfo/Generic/linear-dbg-value.ll
    LLVM :: DebugInfo/X86/live-debug-vars-discard-invalid.mir
    LLVM :: LTO/X86/codemodel-2.ll
    LLVM :: ThinLTO/X86/cfi-devirt.ll
    LLVM :: ThinLTO/X86/devirt-after-icp.ll

Comment 30 Reid Kleckner 2018-10-24 14:34:53 PDT

After r345197 I see only 20 failures:

Failing Tests (20):                                                       
    LLVM :: CodeGen/X86/O0-pipeline.ll
    LLVM :: CodeGen/X86/O3-pipeline.ll
    LLVM :: CodeGen/X86/PR37310.mir
    LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll
    LLVM :: CodeGen/X86/branch_instruction_and_target_split_perf_nops.mir
    LLVM :: CodeGen/X86/code-model-elf-memset.ll
    LLVM :: CodeGen/X86/code-model-elf.ll
    LLVM :: CodeGen/X86/fentry-insertion.ll
    LLVM :: CodeGen/X86/icall-branch-funnel.ll
    LLVM :: CodeGen/X86/indirect-branch-tracking.ll
    LLVM :: CodeGen/X86/large-pic-string.ll                   
    LLVM :: CodeGen/X86/memcmp-mergeexpand.ll
    LLVM :: CodeGen/X86/patchable-prologue.ll
    LLVM :: CodeGen/X86/pr38795.ll                        
    LLVM :: CodeGen/X86/retpoline-regparm.ll
    LLVM :: CodeGen/X86/retpoline.ll
    LLVM :: CodeGen/X86/scheduler-backtracking.ll
    LLVM :: CodeGen/X86/sjlj-eh.ll
    LLVM :: CodeGen/X86/speculative-load-hardening-indirect.ll
    LLVM :: CodeGen/X86/win_coreclr_chkstk.ll

And I have a fix for retpoline in flight:
https://reviews.llvm.org/D53653

Now that we're down to such a small number, maybe we should explicitly annotate just the failing tests as -verify-machineinstrs=0, and mark the x86 target as machine verifier clean to prevent regressions?

Comment 31 Simon Pilgrim 2018-10-25 02:07:26 PDT

(In reply to Reid Kleckner from comment #30)
> After r345197 I see only 20 failures:
> 
> ....
>
> And I have a fix for retpoline in flight:
> https://reviews.llvm.org/D53653
> 
> Now that we're down to such a small number, maybe we should explicitly
> annotate just the failing tests as -verify-machineinstrs=0, and mark the x86
> target as machine verifier clean to prevent regressions?

Yup, that would make sense after D53653 has landed, I'd vote to keep this bug open after that though to track these remaining issues.

Comment 32 Francis Visoiu Mistrih 2018-10-25 09:46:57 PDT

+1 for Reid's suggestion (we should also be careful about tests in DebugInfo/X86 which have some MIR tests)

* r345266 should fix PR37310.mir.
* contacted original author about branch_instruction_and_target_split_perf_nops.mir

Comment 33 Francis Visoiu Mistrih 2018-10-26 09:03:12 PDT

I filed bugs/patches for the existing issues:

LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll: https://bugs.llvm.org/show_bug.cgi?id=39437
LLVM :: CodeGen/X86/branch_instruction_and_target_split_perf_nops.mir: https://reviews.llvm.org/D53767
LLVM :: CodeGen/X86/icall-branch-funnel.ll: https://bugs.llvm.org/show_bug.cgi?id=39436
LLVM :: CodeGen/X86/indirect-branch-tracking.ll: https://bugs.llvm.org/show_bug.cgi?id=39439
LLVM :: CodeGen/X86/pr38795.ll: https://bugs.llvm.org/show_bug.cgi?id=39440
LLVM :: CodeGen/X86/retpoline-regparm.ll: https://reviews.llvm.org/D53653, https://bugs.llvm.org/show_bug.cgi?id=38391
LLVM :: CodeGen/X86/retpoline.ll: https://reviews.llvm.org/D53653, https://bugs.llvm.org/show_bug.cgi?id=38391
LLVM :: CodeGen/X86/scheduler-backtracking.ll: https://bugs.llvm.org/show_bug.cgi?id=39452
LLVM :: CodeGen/X86/sjlj-eh.ll: https://bugs.llvm.org/show_bug.cgi?id=39439
LLVM :: CodeGen/X86/speculative-load-hardening-indirect.ll: https://bugs.llvm.org/show_bug.cgi?id=39451
LLVM :: CodeGen/X86/win_coreclr_chkstk.ll: https://bugs.llvm.org/show_bug.cgi?id=38376

We should be ready to turn it on by default.

Comment 34 Francis Visoiu Mistrih 2018-10-26 09:03:29 PDT

I filed bugs/patches for the existing issues:

LLVM :: CodeGen/X86/avx512-regcall-NoMask.ll: https://bugs.llvm.org/show_bug.cgi?id=39437
LLVM :: CodeGen/X86/branch_instruction_and_target_split_perf_nops.mir: https://reviews.llvm.org/D53767
LLVM :: CodeGen/X86/icall-branch-funnel.ll: https://bugs.llvm.org/show_bug.cgi?id=39436
LLVM :: CodeGen/X86/indirect-branch-tracking.ll: https://bugs.llvm.org/show_bug.cgi?id=39439
LLVM :: CodeGen/X86/pr38795.ll: https://bugs.llvm.org/show_bug.cgi?id=39440
LLVM :: CodeGen/X86/retpoline-regparm.ll: https://reviews.llvm.org/D53653, https://bugs.llvm.org/show_bug.cgi?id=38391
LLVM :: CodeGen/X86/retpoline.ll: https://reviews.llvm.org/D53653, https://bugs.llvm.org/show_bug.cgi?id=38391
LLVM :: CodeGen/X86/scheduler-backtracking.ll: https://bugs.llvm.org/show_bug.cgi?id=39452
LLVM :: CodeGen/X86/sjlj-eh.ll: https://bugs.llvm.org/show_bug.cgi?id=39439
LLVM :: CodeGen/X86/speculative-load-hardening-indirect.ll: https://bugs.llvm.org/show_bug.cgi?id=39451
LLVM :: CodeGen/X86/win_coreclr_chkstk.ll: https://bugs.llvm.org/show_bug.cgi?id=38376

We should be ready to turn it on by default.

Comment 35 Francis Visoiu Mistrih 2018-10-29 10:01:11 PDT

Committed the switch as https://reviews.llvm.org/rL345513. Will keep an eye on the bots. Feel free to revert if I'm not reactive enough.

Comment 36 Simon Pilgrim 2018-10-29 12:53:22 PDT

(In reply to Francis Visoiu Mistrih from comment #35)
> Committed the switch as https://reviews.llvm.org/rL345513. Will keep an eye
> on the bots. Feel free to revert if I'm not reactive enough.

I've put isMachineVerifierClean back at rL345528 to fix some ThinLTO test failures - I've left your test files changes though. Please can you take a look?

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13629/steps/test-check-all/logs/stdio

Comment 37 Francis Visoiu Mistrih 2018-10-30 05:20:37 PDT

(In reply to Simon Pilgrim from comment #36)
> Please can you take a look?
> 
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/
> builds/13629/steps/test-check-all/logs/stdio

Thanks!

* Clang fix: r345591
* LLVM fix + re-enable: r345593

Comment 38 Reid Kleckner 2019-09-06 16:44:26 PDT

(In reply to Francis Visoiu Mistrih from comment #37)
> Thanks!
> 
> * Clang fix: r345591
> * LLVM fix + re-enable: r345593

Marking fixed.

Separately, I was wondering if maybe the machine verifier should be enabled somehow in +asserts builds, or controlled by some llc flag that's always set when lit calls llc, so that we get earlier detection of issues.