Committed in r338278. (https://reviews.llvm.org/rL338278)

Oh, it turns out this isn't just Windows. It's just that the verifier was running on those bots. Doh.

It seems like the issue is that on Windows, we also insert a 'Verify generated machine code' pass.

Sorry for the late response. Looking into the test failure now.

Updated the diff. We now just look over the GPR64 register class instead of callee-saves.

Committed in r338133. (https://reviews.llvm.org/rL338133)

LGTM

This looks good to me.

LGTM, thanks for catching that!

LGTM

LGTM

Committed in r336040.

Updated the patch so that it relies on the changes in D48776. That patch provides the scaffolding for allowing the outliner to be turned on by default by some target. This one flips the switch on AArch64 for -Oz.

Committed in r335986.
https://reviews.llvm.org/rL335986

Removed the reference to enable-linkonceodr-outlining, since it was confusing.

This was actually committed in r335887.

Argh. I accidentally pushed https://reviews.llvm.org/D48682 instead of this. I'll revert it and push this instead. I haven't had enough coffee this morning.

Committed in r335872.

Yeah this is too big. I'll split this up into a few patches then update this one to just reflect turning the outliner on once I'm done...

Committed in r335758 (https://reviews.llvm.org/rL335758).

Updated diff.

In D47655#1144273, @efriedma wrote:

Nevermind, the issue is my fault; should be (MachineBasicBlock::reverse_iterator)front(), not ++(MachineBasicBlock::reverse_iterator)front(). The resulting issue is tricky to debug because MachineInstrs are a circular linked list.

Ah, okay, I'll update the patch with that in a second.

Thanks! Committed in r335658.

Updated diff to actually fix the LRU stuff (oops).

Fixed my mistake using LiveRegUnits. This just walks back across the entire MBB now, so that we know if a register is live across the candidate.

Updated the patch so that it no longer causes issues for the AMDGPU target. The outliner is now only added to the pass pipeline if a target specifies that it supports it in its TargetOptions. After this, whether or not a target supports the outliner must be defined within a specific TargetMachine (similar to GlobalIsel).

Ping! :)

This would make much more sense IMO. Especially for passes with long names. (For example, I'd much rather see "patchable-function" than "Implement the 'patchable-function' attribute" in the JSON)

Fixed comments.

• Added a comment for saving/restoring LR
• Removed LRUOut, since it's not necessary here, and incurs unnecessary calculation
• LRUIn -> LRU

Updated patch to handle the live-in case. Updated the test to be more explicit as well.

Closed in r333952 (https://reviews.llvm.org/rL333952)

In D47553#1119498, @asb wrote:

I think I can disable outlining for an entire function using isFunctionSafeToOutlineFrom

Yeah, that'll work. It's conservative, but it will ensure that the outliner will never touch the function, and thus, won't touch the instructions (or anything between them).

Got rid of the whitespace changes and remembered to pass -U999999 this time.

Cool! LGTM.

Ah, you’re right.

Committed as r332739.

Updated patch to address review.

A few changes here after running this on some more complicated code.