This is an archive of the discontinued LLVM Phabricator instance.

Add new MachineFunction property FailsVerification
ClosedPublic

Authored by foad on Oct 8 2021, 3:16 AM.

Details

Summary

TargetPassConfig::addPass takes a "bool verifyAfter" argument which lets
you skip machine verification after a particular pass. Unfortunately
this is used in generic code in TargetPassConfig itself to skip
verification after a generic pass, only because some previous target-
specific pass damaged the MIR on that specific target. This is bad
because problems in one target cause lack of verification for all
targets.

This patch replaces that mechanism with a new MachineFunction property
called "FailsVerification" which can be set by (usually target-specific)
passes that are known to introduce problems. Later passes can reset it
again if they are known to clean up the previous problems.

Diff Detail

Event Timeline

foad created this revision.Oct 8 2021, 3:16 AM
foad requested review of this revision.Oct 8 2021, 3:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 8 2021, 3:16 AM

This is an RFC to see if people like the idea.

Known issues:

  1. I'm not sure if the new "Verifies" property needs to be serialised in .mir files.
  2. When you look at the TargetMachine class for a particular target, it's not very easy to see where the "Verifies" flag gets turned off and on -- you have to look into the individual passes. It would be easy to have it turned off at one point in the middle of the pass pipeline, and forget to turn it on again later.

As discussed in https://reviews.llvm.org/D111386 I have a feeling that some targets can likely be improved by moving code from addPreEmitPass to addPreEmitPass2. But we should probably discuss this independently of this patch, since I have a feeling that one way or another we won't end up with 100% of things fixed.

I am in favor of this change and just have some nitpicks.

llvm/include/llvm/CodeGen/MachineFunction.h
152–166

Can we use a flag where the default/desired state is not set?

llvm/lib/CodeGen/MachineFunction.cpp
160

See above (when switching to DisableVerification).

llvm/lib/CodeGen/MachineVerifier.cpp
296–297

FWIW: I don't have high hopes for this flag ever disappearing once we introduce it and would tend to drop the comment (but no strong opinion you can keep it if you want).

llvm/lib/Target/AMDGPU/AMDILCFGStructurizer.cpp
130

So, there's this thing I've seen other projects do, where they file tickets in the bugtracker and reference those in code. I know we don't usually do this in LLVM yet, but maybe we can set a new precedent here, what do you think?

llvm/lib/Target/AMDGPU/SILowerControlFlow.cpp
797

As above.

llvm/lib/Target/Hexagon/HexagonVLIWPacketizer.cpp
206

as above

This is an RFC to see if people like the idea.

Known issues:

  1. I'm not sure if the new "Verifies" property needs to be serialised in .mir files.

Yes I think so.

  1. When you look at the TargetMachine class for a particular target, it's not very easy to see where the "Verifies" flag gets turned off and on -- you have to look into the individual passes. It would be easy to have it turned off at one point in the middle of the pass pipeline, and forget to turn it on again later.

Well, I don't think we have a better solution. Regardless it's better than what we currently have.

foad updated this revision to Diff 379954.Oct 15 2021, 3:39 AM

Invert the sense of the attribute. Split the patch into two.

foad retitled this revision from RFC: A new way of skipping machine verification after problematic passes to Add new MachineFunction property FailsVerification.Oct 15 2021, 3:43 AM
foad edited the summary of this revision. (Show Details)
foad marked 3 inline comments as done.Oct 15 2021, 3:44 AM

Known issues:

  1. I'm not sure if the new "Verifies" property needs to be serialised in .mir files.

Yes I think so.

Done.

llvm/lib/CodeGen/MachineVerifier.cpp
296–297

I'm an optimist!

llvm/lib/Target/AMDGPU/AMDILCFGStructurizer.cpp
130

I'm happy to do this in principle.

MatzeB accepted this revision.Oct 15 2021, 10:33 AM

LGTM

This revision is now accepted and ready to land.Oct 15 2021, 10:33 AM
This revision was landed with ongoing or failed builds.Oct 18 2021, 2:27 AM
This revision was automatically updated to reflect the committed changes.
foad marked an inline comment as done.
foad added inline comments.Oct 18 2021, 2:36 AM
llvm/lib/Target/AMDGPU/AMDILCFGStructurizer.cpp
130

Done for the AMDGPU SILowerControlFlow case: a129932b0d45949a884cee90726bf90217c2e737
For the Hexagon packetizer case, it seems like there's more debate over whether there's really a "bug" and how it could be "fixed".

arsenm added inline comments.Oct 18 2021, 9:46 AM
llvm/include/llvm/CodeGen/MIRYamlMapping.h
726

This should not need explicit serialization. The verifier runs after mir parsing anyway.

It should also be illegal to clear this after it’s set

foad added inline comments.Oct 18 2021, 10:38 AM
llvm/include/llvm/CodeGen/MIRYamlMapping.h
726

This should not need explicit serialization.

Why? It means "this function has known problems that I haven't fixed yet so please don't run the verifier on it".

It should also be illegal to clear this after it’s set

Why?

arsenm added inline comments.Oct 18 2021, 1:01 PM
llvm/include/llvm/CodeGen/MIRYamlMapping.h
726

Oh, I misread the intent of this change. I assumed this was solving a problem I've run into where a pass introduces a compilation failure, and as a result ends up in some invalid state where the verifier crashes. For example this happens when the register allocator fails and emits an error, but the compilation still needs to continue.

I don't love the idea of allowing functions to fail the verifier, and then be fixed up later. Once the verifier fails a function should be dead.

MatzeB added inline comments.Oct 18 2021, 2:03 PM
llvm/include/llvm/CodeGen/MIRYamlMapping.h
726

Yeah, FailsVerifier is an intentional decision by pass authors, that they are aware that the pass produces MIR that will not pass the verifier.

I am pretty sure everyone would be happier to just force every machine function to very, but it's a practical concern to get to that state. Before this change we had verification completely disable for a number of passes, with this change at least we can enable verification for all passes in general and the instances where this isn't the case target authors can work around by setting the FailsVerification flag and fixing things on their own pace...