Hello all,

Can anyone commit this on my behalf please?

@dexonsmith Is it better now?

Thank you for your comment. I agree with what you say, however, I think you may understand that we should have had this discussion before this patch in https://bugs.llvm.org/show_bug.cgi?id=37792 😭

Thanks for your comment Greg. Please feel free to tell me if you need anything else I'll try to update the patch.

-S already inserts a -print-module to the pipeline. But I can explicitly add that option to the command line if you want

Friendly ping!

Thank you for reviewing this. Unfortunately I do not have the commit access, can you do it on my behalf please?
Thank you again

Is it better now?

I think it would be oddly divergent if these are analyses in one pass manager and not the other, which is why I'm pushing to understand what we'll do for both.

Addressed review comment.

No don't get me wrong, this patch is supposed to fix the issue in the LegacyPassManager, and I do not intend to change anything about the new pass manager in this patch.

Thanks for taking a look at this. However, IIRC, the new pass manager does not have print-before/after(-all) mode yet. That is the next thing that I want to do (if you agree, of course)

I get it now. Thank you for your time. So anything else that needs to be fixed? Otherwise I'll tackle the verify-each mode

Hmmm, sorry but I still don't understand how do we remove declare @llvm.dbg.* from the IR though? Or you think that this is not necessary?

Yes, you'll have to do opt -strip-debug -strip-dead-prototypes. What is done in strip-dead-prototypes is exactly what we do here though... I'm not sure what would cause the ThinLTO test fail...

In D45556#1117242, @HsiangKai wrote:

In D45556#1114350, @tyb0807 wrote:

Thank you for the patch.

It seems to me that with requireLabelBeforeInsn, the label will later be emitted as a temporary symbol with a unique but unspecified name (in DebugHandleBase::beginInstruction()). Is it correct?

Yes, I generate a temporary label before the label intrinsic. In this way, I could get the address of the label afterward.

Yes, I mean that the label will later be named differently in the asm file than in the source? I don't know if this is something we should care about though, I'm just speaking from an user point of view

Thank you for the patch.

Yes please commit this on my behalf.

Sure, the patch is updated accordingly.

Context added

Addressed review comments. Thank you for the help

The test is now simplified. Please tell me if you really want to remove -strip-debugify option and use -strip-debug instead.

Address review comments. Other comments inlined

UPD: There are 3 regression tests that declare functions starting with llvm.dbg. (e.g. declare void @llvm.dbg.func.start(metadata) nounwind readnone) and are failing:

• Linker/2009-09-03-mdnode.ll
• Transforms/SimplifyCFG/2003-08-17-FoldSwitch-dbg.ll
• Transforms/SimplifyCFG/dbginfo.ll

Thank you Vedant. I do not have commit access, please commit this for me.

Sorry it was a local change, forgot to remove it before diffing. Please tell me if there's any way to handle local change while still being able to create patch properly.

Addressed review comments.

Address review comments. Now we print out the module when check-debugify reports an error. I guess another important information should be the optimization pass that makes check-debugify fail, but I'm not sure how to get that information though.

I've posted a reduced test case in https://bugs.llvm.org/show_bug.cgi?id=37149.

@aprantl Yes that is exactly what I am doing.
@rob.lougher As you pointed out, I was hoping that this change would not change the splitting in RegAlloc, but apparently it is not the case. The test added in D35953 does not pass anymore. Instead of

[0x000000000000001f, 0x000000000000003c): DW_OP_reg3 RBX

we now have

[0x000000000000000e,  0x0000000000000013): DW_OP_reg2 RCX
[0x0000000000000013,  0x000000000000003c): DW_OP_reg3 RBX

I do not understand why though... RegAlloc should not be broken this way :(. I'll update a reduced test case reflecting the PR37149's issue so you can tell me how it should be fixed.

Urgh, sorry but ... what new check? The only check is just transforming SmallSet::count() into SmallDenseMap::find() + comparing with SmallDenseMap::end(), so just to check whether the interval start was trimmed to the lexical scope (which is already commented in L1210).

Hello Vedant,

Hmmm, the problem is in AssemblyWriter::printFunction(), we already print a newline character at the start of the function, so in fact this issue only raises when we print ModulePasses. Removing the newline character printing in AssemblyWriter::printFunction() will lead to this:

@x = common dso_local global i32 0, align 4
@y = common dso_local global i32 0, align 4
@z = common dso_local global i32 0, align 4
; Function Attrs: noinline nounwind uwtable

instead of this:

@x = common dso_local global i32 0, align 4
@y = common dso_local global i32 0, align 4
@z = common dso_local global i32 0, align 4

svn blame leads me to this

So for now, with -print-after-all or -print-before-all options in opt, we have the banner and the first line of the IR Module on a same line, e.g:

*** IR Dump After Force set function attributes *** ; ModuleID = '<stdin>'
source_filename = "main.c"
...