LGTM. Thanks!

Could you change the verification/validation to "basic correctness"? That would better reflect the intended meaning.

I committed a small patch (https://reviews.llvm.org/rGa721ddbae983), it changes releaseTopNode and releaseBottomNode, you'll need to rebase before merging.

LGTM

The limitation is really that we can't reorder basic blocks after the BB sections pass. I've been thinking about it some more and I think we could move the packetization into pre-emit2. There weren't any other issues uncovered when I tried it locally.

I guess a flag DoNotVerify on the MF should be ok as well.

The problem is that the packet rules can be target-specific (there are some very Hexagon-specific situations that are allowed/disallowed). I'd rather have an option to turn off the verifier on packetized code, than to make significant efforts to make the verifier work with it. We do have our own verification code in MC that validates packets, so the MIR verifier adds little value for us.

One problem that came up is that the "BB Sections" pass runs before pre-emit2. This imposes restrictions on what kinds of optimizations we can run in pre-emit2. If we could move BB Sections until after pre-emit2, it would be a lot better for us.

LGTM. Thanks!

That sounds reasonable. Let me try that locally (downstream). If it works, then let's do it.

I guess you could add a target hook to TargetMachine to query whether the target wants to run the verifier at that stage, e.g.

addPass(createSomePreEmitPass(), TM->verifyCode(kPreEmit));

or something like that.

There is nothing to fix in the packetizer. On Hexagon the order of instructions inside of packets generally doesn't matter (with a few exceptions). The verifier simply doesn't handle that, and that's why it's disabled.

Committed in https://reviews.llvm.org/rGa72763af67a0.

Edit: this comment is about AArch64. I didn't try to see if there are any other compilation errors.

Ah, you're right, I didn't look closely enough.

Sorry, the emails that I'm getting from the @-mentions look exactly the same as any other email from phabricator to llvm-commits, and with hundreds of these per day I only look at a few...

Added definition of OptBisect::Disabled.

Added resetting of the counter when new limit is set.

Yes, that's exactly what happens. The project uses LLVM as a code generator for multiple targets. The OptBisector object is constructed the first time it's queried by shouldRunPass, which happened during the code generation for the first target. We set up the second target by passing some extra flags to ParseCommandLineOptions, but passing -opt-bisect-limit at this time no longer has any effect (i.e. the setting from the construction time remains).