Nov 14 2018
Jul 23 2018
Can anyone commit this on my behalf please?
Jul 20 2018
@dexonsmith Is it better now?
Jul 18 2018
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 😭
Jul 17 2018
Thanks for your comment Greg. Please feel free to tell me if you need anything else I'll try to update the patch.
Jul 16 2018
-S already inserts a -print-module to the pipeline. But I can explicitly add that option to the command line if you want
Jul 14 2018
Jul 13 2018
Jul 11 2018
Jul 6 2018
Thank you for reviewing this. Unfortunately I do not have the commit access, can you do it on my behalf please?
Thank you again
Jul 5 2018
Jun 29 2018
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.
Jun 28 2018
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)
Jun 4 2018
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...
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
May 29 2018
Thank you for the patch.
May 22 2018
Yes please commit this on my behalf.
May 18 2018
Sure, the patch is updated accordingly.
May 16 2018
Addressed review comments. Thank you for the help
May 15 2018
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
May 14 2018
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:
May 13 2018
Thank you Vedant. I do not have commit access, please commit this for me.
May 12 2018
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.
May 11 2018
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.
May 10 2018
I've posted a reduced test case in https://bugs.llvm.org/show_bug.cgi?id=37149.
May 9 2018
@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).
May 8 2018
May 7 2018
Apr 23 2018
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
Apr 18 2018
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" ...