In D144006#4656399, @aeubanks wrote:

In D144006#4656383, @dzhidzhoev wrote:

In D144006#4656371, @aeubanks wrote:

Is there any issue with mixing IR built with LLVMContext::enableDebugTypeODRUniquing() and without? I'm suspecting that ThinLTO is mixing Rust and Clang IR which set that differently.

Apparently, it's an issue with ThinLTO that might be caused by a change in MetadataLoader https://github.com/llvm/llvm-project/pull/68986.
Is there a way to get a repro like this one https://bugs.chromium.org/p/chromium/issues/detail?id=1487910#c3 if it's not too complicated?

I've shared the repro tar with your commit email address, sorry it's so big. I tried linking again with the revert and now it looks like the debug info verifier is firing instead. Do you also need a repro tar with everything built with the revert?

In D144006#4656728, @jmorse wrote:

Hi,

Just to note that we've been seeing LTO crashes as a result of rG3b449bd46a11a (now reverted on trunk), which @StephenTozer has kindly reduced down to:

https://gist.github.com/jmorse/b0248c3c9f9195487ffd7c7431a8d15e

Which triggers the assertion: DwarfDebug.cpp:2335: virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *): Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms && "getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed. If you revert-the-revert rG6beddd668 that is.

I haven't familiarised myself with this patch series (while greatly appreciating that it exists!), so perhaps this is already obvious but: This particular assertion is a check that no additional lexical scopes are discovered during DWARF emission that weren't found during the earlier building of the lexical-scopes-map, which enumerates all scopes/inlining-chains for all instructions' DebugLocs. If any more unexpectedly appear after that, I believe there's a risk that a container for lexical scopes gets reallocated, causing random crashes. I see there are now types in the retainedNodes field for DISubprograms with "scope" fields (EDIT: !53 in the reproducer), I imagine that the discovery of those lexical scopes which weren't reachable from instructions might be causing the assertion.

Just to note that we've been seeing LTO crashes as a result of rG3b449bd46a11a (now reverted on trunk), which @StephenTozer has kindly reduced down to:

Still LGTM

Some other changes that have filtered in:

• CodeGenPrepare::placeDbgValues deliberately removes dbg.value intrinsics, so I've removed the assertion in Instruction::eraseFromParent. We're in a much stronger position wrt. binary-identicalness so I'm not worried about this.
• There are some fixes for TrailingDPValues now being stored in LLVMContextImpl, but they're all mechanical.
• Some things have been renamed / reworded as suggested.
• One of the comments in the big-comment in spliceDebugInfo was wrong, "Or if we didn't want to insert at the head of Dest"... but the example had the "head" bit set to true. I've flipped this to the correct way, but figured I'd highlight this as being deliberate rather than an accident. If we don't want to insert before dbg.values on an iterator, the "head" bit should be false.

(Addressing comments, ticket boxes etc).

It looks like the major parts of the compile-time regression was down to the Metadata-handling changes in D153990, specifically handling DIArgList differently to other MDNodes causes a big IR-switch statement to not be optimised away, and that has a knock-on effect on inlining decisions all around Metadata.cpp. This is unfortunate, but it's also subject to change, as we're planning on re-profiling and then reimplementing how metadata-tracking works at a later date, once we're confident there are no more invasive changes. I've had some close chats with @StephenTozer and he's got some ideas on what we could change in the future to avoid an eventual regression.

In D144006#4656383, @dzhidzhoev wrote:

In D144006#4656371, @aeubanks wrote:

Is there any issue with mixing IR built with LLVMContext::enableDebugTypeODRUniquing() and without? I'm suspecting that ThinLTO is mixing Rust and Clang IR which set that differently.

Apparently, it's an issue with ThinLTO that might be caused by a change in MetadataLoader https://github.com/llvm/llvm-project/pull/68986.
Is there a way to get a repro like this one https://bugs.chromium.org/p/chromium/issues/detail?id=1487910#c3 if it's not too complicated?

In D144006#4656371, @aeubanks wrote:

Is there any issue with mixing IR built with LLVMContext::enableDebugTypeODRUniquing() and without? I'm suspecting that ThinLTO is mixing Rust and Clang IR which set that differently.

In D144006#4656350, @aeubanks wrote:

Heads up, we're seeing issues from this in Chrome again, will try to post a reduced repro (https://crbug.com/1500022)

The reduced repro I found crashed very far back, so I'm guessing this patch caused bad debug info which triggers an existing issue that doesn't handle bad debug info.

another observation, opt complained about some debug info due to setting LLVMContext::enableDebugTypeODRUniquing() and stripped it away, but llc happily accepted the debug info and crashed with the assertion above when emitting assembly.

Is there any issue with mixing IR built with LLVMContext::enableDebugTypeODRUniquing() and without? I'm suspecting that ThinLTO is mixing Rust and Clang IR which set that differently.

../../llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:110: void llvm::DwarfFile::addScopeVariable(LexicalScope *, DbgVariable *): Assertion 'Ret.second' failed.

Heads up, we're seeing issues from this in Chrome again, will try to post a reduced repro (https://crbug.com/1500022)

In D144007#4651924, @jmmartinez wrote:

Hi @dzhidzhoev !
What's missing to land the rest of the patches? I missed the last discussions and I saw you just rebased this one.

In D154080#4656037, @nikic wrote:

FYI this has also increased time to build clang by a whopping 3%. My first suspicion is that your DebugProgramInstruction.h include in BasicBlock.h pulls in the kitchen sink.

FYI this has also increased time to build clang by a whopping 3%. My first suspicion is that your DebugProgramInstruction.h include in BasicBlock.h pulls in the kitchen sink.

I'm slightly surprised to see that this is regressing -g performance a bit [0], I'd thought I'd kept all these patches from actually being _used_ by LLVM until later ones land and switches are enabled. Two possibilities to my mind:

• It's the linear walk over the blocks instructions to clear DPMarkers at the end. That's something we can polish later, and #ifdef guard for now.
• Something in the metadata maps added in D153990 is getting slower? If so that must be down to branching?

Closed by rG7d77bbef4ad9230 . Note that I lost one of the hunks in IRMover for assigning IsNewDbgInfoFormat as that was leading to some tests assertions where slightly-incompatible objects are linked between IR files (link-global-to-func.ll, which should fail, not assert). This hunk will instead appear in the next patch series once I'm confident enough there aren't any unintended side-effects.

Closed by rG7d77bbef4ad9230 .

LGTM + a few comments

LGTM

Unittests LGTM. Comprehensive coverage yet easy to read, nice.

SGTM so far, just working my way through the unittests now.

Looking at the history-diff, I've also added some flag-maintenance in IRMover, which I believe is involved in moving modules around. I think there were just a few code paths there where we start constructing replacement modules/functions, and have to start off with the flag being correct. (This is all cost+overhead of having the two implementations available right now).

Address review comments of various forms; also add the plumbing for replacing TrailingDPValues with an LLVMContext stored map of Block<=>TrailingDPValues.

Other bits and pieces that have changed, now that I look at the history-diff:

• setTailCall() is called on DPValues that are converted back to dbg.values. This is consistent with the rest of LLVM.
• I've added a global static DPMarker with an empty StoredDPValues field, so that we can always produce a legitimate, empty range of DPValues in the added getEmptyDPValueRange, from methods where there's no debug-info.

Here's a revised patch -- I've shifted the location of the TrailingDPValues data structure into LLVMContextImpl, as it seems we only ever have one or two blocks with trailing DPValues at a time. It doesn't make sense to bloat BasicBlock with a dedicated field for a special case. I'm planning on plumbing this through BasicBlock, as a result the relevant useful methods turn up in the next patch (D154080), so I've left an llvm_unreachable in DPMarker::removeMarker until that lands.

Sitrep on the TrailingDPValues situation -- we had a chat offline, and this is sort of a leftover from an earlier prototype where all DPValues were in a "shadow" list that existed behind the main instruction-list, and had a total order on them. TrailingPDValues was the "end" of that list. The model we've ended up with doesn't have that total order (because collections of DPValues are split between instructions) but we still use TrailingDPValues to pretend it is, so there's a bit of extra reshuffling that has to happen.

@dyung has set up a buildbot for this (thanks Doug!), landing shortly.

In D144006#4651955, @hans wrote:

We're hitting an assert after this change:

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2331:
virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *):
Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms &&
"getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed.

See https://bugs.chromium.org/p/chromium/issues/detail?id=1487910#c3 for a reproducer.

I'll revert until it can be investigated/fixed.

The code changes here look good, but it's time to be annoying about the tests -- most of them appear to run the optimisation pipelines, which is testing all of LLVM as well as clang in these tests. Possibly a simple fix to that is to put these in cross-project-tests. Otherwise, I believe these should be only testing the plain codegen output without optimisations at all, i.e. --disable-llvm-passes.

Said buildbot PR: https://github.com/llvm/llvm-zorg/pull/48

LGTM with some minor questions

LGTM

(Missed inline comments being submitted...)

New changes LGTM. There are still a few outstanding questions to look at (including the inline question for @StephenTozer) so I'll hold off on Accepting just yet.

Implement review feedback from Orlando.

These blocks of code should be considered transitory as we (hopefully) move from one debug-info format to another.

LGTM once inline comments have been addressed

We're hitting an assert after this change:

Hi @dzhidzhoev !
What's missing to land the rest of the patches? I missed the last discussions and I saw you just rebased this one.

Rebase

Code changes LGTM pending inline comments. I haven't looked at the tests yet.

(NB: I'm also going to try and get one of our buildbots building with the cmake flag set so that this doesn't immediately commit uncovered code.)

LGTM (pending clang-formatting if not already, plus a few nits).

Are you able to post the test source or an unoptimized reproducer?

In D158185#4648729, @fdeazeve wrote:

I've just noticed that, for reasons I am still investigating, the optimizer produced this expression in some test:

Actually, I think that expression might be invalid? That argument 1 is supposed to mimic the DWARF specification, i.e., it attempts to specify the length of the operations that are evaluated upon function entry. We require it to be 1 because we always want to be just a "register" operation. It's not clear what the meaning would be for a variadic expression

I've just noticed that, for reasons I am still investigating, the optimizer produced this expression in some test:

Nice and easy

In D157615#4647235, @StephenTozer wrote:

In D157615#4646848, @dblaikie wrote:

Might be worth rewording the commit, or splitting it - I'd say the introduction of optdebug should be the noteworthier part of this patch (or whichever patch introduces it) - so either "this patch adds optdebug, and a first/exemplar use of it in postra scheduler" or split it into a patch that just adds the attribute and no uses, and one that adds the use.

SGTM, the scope of this patch has increased as-of the latest update. That being said AFAIK Github PRs don't currently have support for stacked PRs, so I imagine I'll need to have one review up at a time.

In D159468#4646851, @dblaikie wrote:

Probably worth a FIXME and a bug filed about supporting different location kinds? (like, really - we can't describe a variable as being partly in memory, and partly in a register? That doesn't sound right to me... I'd have thought we would've had support for that a while ago, but I don't follow the variable location parts of DWARF in as much detail, so maybe it is)

In D157615#4646848, @dblaikie wrote:

Might be worth rewording the commit, or splitting it - I'd say the introduction of optdebug should be the noteworthier part of this patch (or whichever patch introduces it) - so either "this patch adds optdebug, and a first/exemplar use of it in postra scheduler" or split it into a patch that just adds the attribute and no uses, and one that adds the use.

In D157616#4644101, @jmorse wrote:

LGTM, with the rider that I'm not sure what the policy is on putting the python test in there. It's fundamentally a debug-info quality test, which is slightly different to the functional tests that we have elsewhere.

Probably worth a FIXME and a bug filed about supporting different location kinds? (like, really - we can't describe a variable as being partly in memory, and partly in a register? That doesn't sound right to me... I'd have thought we would've had support for that a while ago, but I don't follow the variable location parts of DWARF in as much detail, so maybe it is)

Might be worth rewording the commit, or splitting it - I'd say the introduction of optdebug should be the noteworthier part of this patch (or whichever patch introduces it) - so either "this patch adds optdebug, and a first/exemplar use of it in postra scheduler" or split it into a patch that just adds the attribute and no uses, and one that adds the use. (I'd lean towards splitting it up, personally & I guess maybe moving to github pull requests in the process, perhaps)

Thanks for the explanation, it makes sense!

Check for isSingleLocationExpression in more places and make other checks (isEntryValue() and similar) contingent on that check.

In D158185#4645353, @fdeazeve wrote:

Hi @StephenTozer, could you elaborate on what these failures are? I am concerned because, ever since D133926 was merged, there are some methods that were left with an incorrect implementation, like startsWithDeref or isEntryValue. It would be nice if we could address those.
Is the proposed fix here revealing a larger problem that may cause D133926 to be rethought?

However, I've found the patch triggers some errors when running on the llvm test suite, and the variadic check really isn't that expensive I think, so I'm going to rewrite the patch to do a bit more.

Rebased

In D159468#4643380, @scott.linder wrote:

In D159468#4641937, @fdeazeve wrote:

In D159468#4641242, @scott.linder wrote:

In D159468#4639858, @fdeazeve wrote:

@scott.linder This is a patch I'd like to submit in the same area where your other patches are (https://reviews.llvm.org/D158675)
I don't mind rebasing if you think they will be merged soon!

I'm just running some final tests on our CI, and hopefully all goes well and they land today. Otherwise, I am also happy to rebase after you!

Awesome! I don't mind waiting an extra day or so! :)

Thank you for waiting, and sorry it took through the weekend; I was out unexpectedly on Friday.

I just landed the series, ending with 43331461954939032a03621998c30ac90299ad40

Hopefully there are no regressions and it sticks, in which case you should be good to rebase now!

LGTM, with the rider that I'm not sure what the policy is on putting the python test in there. It's fundamentally a debug-info quality test, which is slightly different to the functional tests that we have elsewhere. The failure mode would be where some optimisation decision changes, we get a non-perfect but acceptable debug-info output, and an optimisation writer is inconvenienced by a test that "can't be correctly updated", as it were.

In D159468#4641937, @fdeazeve wrote:

In D159468#4641242, @scott.linder wrote:

In D159468#4639858, @fdeazeve wrote:

@scott.linder This is a patch I'd like to submit in the same area where your other patches are (https://reviews.llvm.org/D158675)
I don't mind rebasing if you think they will be merged soon!

I'm just running some final tests on our CI, and hopefully all goes well and they land today. Otherwise, I am also happy to rebase after you!

Awesome! I don't mind waiting an extra day or so! :)

In D151465#4642321, @aprantl wrote:

@StephenTozer Yes, there are green dragon errors. It looks like -lstdc++ is hardcoded. On Darwin we usually only have libc++. Could you make that configurable?

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/59897/consoleFull#12109776838254eaf0-7326-4999-85b0-388101f2d404

@StephenTozer Broken greendragon tests temporarily XFAILed with 37a20cc68f545647e614c5ba4ae311dc3fd277e9

@StephenTozer Yes, there are green dragon errors. It looks like -lstdc++ is hardcoded. On Darwin we usually only have libc++. Could you make that configurable?

In D159484#4641955, @probinson wrote:

Please use GitHub for new patches.

Please use GitHub for new patches.

In D159468#4641242, @scott.linder wrote:

In D159468#4639858, @fdeazeve wrote:

@scott.linder This is a patch I'd like to submit in the same area where your other patches are (https://reviews.llvm.org/D158675)
I don't mind rebasing if you think they will be merged soon!

I'm just running some final tests on our CI, and hopefully all goes well and they land today. Otherwise, I am also happy to rebase after you!

Fix incorrect comment in commit message.

In D159468#4639858, @fdeazeve wrote:

@scott.linder This is a patch I'd like to submit in the same area where your other patches are (https://reviews.llvm.org/D158675)
I don't mind rebasing if you think they will be merged soon!

Since this is DWARF5/ObjectiveC only, and since it resolves more failures than it creates, I'll go ahead and merge it.