In rG0345d88de654259ae90494bf9b015416e2cccacb#953264, @hgreving wrote:

Is this really necessary to remove? For example, our backend is using EntrySU edges for top edges from the basic block entry, in order to account for clearances. It seems to make sense to have a node like this.

I am totally fine with keeping this in-tree, even unused, if it helps several out-of-tree backends. Thanks for speaking up.

LGTM

Can you wrap the condition around the whole file? The rest is not useful without the library anyway.

Won't be back to this anytime soon.

LGTM

This looks great, thanks! Since it's a CodeGen pass, I would suggest using a MIR test instead of an IR one, but I think it's probably easier to read it as it is right now.

In D85809#2218742, @tejohnson wrote:

Just to clarify, I wasn't suggesting putting it in another patch, but just bringing it back here (plus adding in the gold-plugin support). The other patch I was referring to was the follow on patch D85810 where I also suggested adding support to gold-plugin.cpp.

In D85809#2217341, @weiwang wrote:

I have removed the change to llvm-lto

LGTM, thanks for plugging all these options through!

Hi @compnerd, it looks like this fails to link: http://green.lab.llvm.org/green/job/clang-stage1-RA/13171/console

In D84690#2179205, @dblaikie wrote:

Indeed, sorry that fell through & I didn't understand enough about iterators to instead suggest falling back to an input iterator instead of figuring out how to fit the semantics of the forward iterator.

I had an attempt here: https://reviews.llvm.org/D33419, I think similar concerns came up in that review.

In D84207#2164754, @jroelofs wrote:

Not sure why our public bots didn't catch it.

In D81645#2160087, @dantrushin wrote:

In D81645#2159907, @thegameg wrote:

Hi, I see CodeGen/X86/statepoint-vreg.mir failing with UBSAN enabled on our internal bots:

Should be fixed already.
Does your sources include e04fe9aefd4?

Hi, I see CodeGen/X86/statepoint-vreg.mir failing with UBSAN enabled on our internal bots:

LGTM, thanks!

This sounds useful indeed. @fhahn, @anemet might want to take a look.

LGTM, thanks.

Would it be cleaner to make setCodeGenDebugOptions take an ArrayRef<StringRef>?

I think there are a bunch of APIs that have this issue, so I think the general direction is good. I don't expect this to have any memory/compile-time impact, since probably even the smallest input will create the MachineFunctionInfo anyway. Was this the initial intention of having it build lazily?

Address reviewer comments.

LGTM.

Looks pretty straightforward. Thanks!

LGTM, thanks!

There are still a bunch of other users of the headers in tree, but the error doesn't trigger since Pass.h gets included before. Is that worth changing as well?

Thank you, this LGTM!

Thanks Andrew! A few coments inline and below:

LGTM, thanks!

This also fixes https://bugs.llvm.org/show_bug.cgi?id=44253. Is there any update on the ppc reproducer?

LGTM, this looks great, thanks @wmi.

Sorry for the delay.

This is great! Sorry for the delay. More comments inline.

Add test through llvm-lto. More extensive testing of the BinaryFormat logic was added in https://reviews.llvm.org/rG7b0a5683fa09be4e60bc93526aad7b63bbca687c.

Thanks @fpetrogalli and @MaskRay. I did one more cleanup: a32d539798e4 [Target] Remove libObject dependency in lib/Target.

Thanks for working on this, I think in general it looks good.