similar to: [LLVMdev] Proposal: Debug information improvement - keep the line number with optimizations

Hi Patel, Here is second part of my reply. > 2. Proposed Work Plan > > This section defines a proposed work plan to accomplish the > > requirements that we desires. The work plan is broken into several > > distinct phases that follow a logical progression of modifications > > to the LLVM software. > > > > 2.1 Phase 1: Establish the testing

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

John, Mem2reg actually modifies debug information in a way that at least suggests it's trying to maintain debugability. Specifically, it changes llvm.dbg.declare() calls (appropriate for variables that permanently reside in a single place) to llvm.dbg.value() calls (specifying that at this instant, this variable is in this register). In fact, the .bc after inlining and mem2reg

Thanks Devang. Is there any plan on making this implicit in the node creation? Or instead of using DebugLoc in SelectionDAG, use SDDbgValue's instead, or embedding the SDDbgValue in the debug loc itself somehow? This seems like something that shouldn't have to be handled on a case by case basis in the backends. Your thoughts? Thanks, Micah From: Devang Patel [mailto:dpatel at

On Apr 15, 2011, at 2:21 PM, Villmow, Micah wrote: > John/Richard, > I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. > > When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in

Found another bitcode file where a debug symbol is being dropped. In the attached bitcode file, the variable gid is not in the debug output. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Thursday, April 14, 2011 5:31 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Valid debug information being deleted by DAGCombiner I am working

I am working on some debug problems that we are seeing with the x86 backend and OpenCL. The input is linked.bc. There are three debug values, ip, tid and gid. llc -march=x86 linked.bc -o linked-x86.s <-- assembly file has all three values in the debug info section However, if I attempt to optimize the bitcode with the following command: opt -disable-opt -inline-all -mem2reg linked.bc -o

On 4/14/11 8:22 PM, Villmow, Micah wrote: > > Found another bitcode file where a debug symbol is being dropped. > > In the attached bitcode file, the variable gid is not in the debug output. > Dumb question: Have you looked to see if mem2reg is destroying (or not maintaining) the debug information of interest (or put another way, was the variable gid promoted to an LLVM register

John/Richard, I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. During

Hi All, Right now, mem2reg and SRoA strip all debug information off allocas they promote. This means that we lose almost all debug information for local variables when the optimizer is turned on. Here is a proposal to improve the situation: http://nondot.org/sabre/LLVMNotes/DebugInfoVariableInfo.txt Thoughts welcome, -Chris

On Wed, 21 May 2008, Nicolas Capens wrote: > Thanks for the detailed explanations. I have a few remaining questions: > > Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg > and therefore generally preferable? Right. > What would be the code quality implications of using "-dce -simplifycfg" > instead of -adce? As far as I understand the

Hi, I would like to know how much effect these stoppoint calls have on the optimization of the bytecode? DOes insertion of debugging info cause opportunities for optimization (especially interprocedural dead code elimination and interprocedural constant propogation) to be reduced? The -g code is not very readable, so I am not able to confirm this by my own experiment. Thanks! Nikhil On Sat,

Hi, I'm curious that whether we can keep debug information of local variable when in the optimization condition (for example -O2, -O3) in LLVM. For example this simple C source code: int main() { int i = 5; if(i > 5) { return 1; } else { return 0; } } If we compile clang -g a.c, we can get our expected result. We can check and update the local variable

On Tue, Apr 14, 2015 at 03:20:08PM -0400, Gene Cumm wrote: > > I thought I would try to find out how pxelinux copes with this, by trying > > to insert printfs in pxe_init, but nothing gets printed. > > This is normal. Can you give me hint as to why setting > > DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 changes that state of normality? (AFAICT dprintf.h

Hi Chris, Thanks for the detailed explanations. I have a few remaining questions: Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg and therefore generally preferable? What would be the code quality implications of using "-dce -simplifycfg" instead of -adce? As far as I understand the algorithms involved, -dce would hardly ever miss a dead instruction if

I have reason to believe that an odd box that is having boot trouble has three instances of "!PXE" in the chunk of memory that "Method D" should look at. I thought I would try to find out how pxelinux copes with this, by trying to insert printfs in pxe_init, but nothing gets printed. I can spew lots of output if I set DEBUGOPT = -DDEBUG=1 -DDEBUG_STDIO -DCORE_DEBUG=1 but

On Nov 28, 2010, at 3:47 PM, John McCall wrote: > This is well-formed SSA; the alloca instruction %x is in the entry block and thus dominates both the store in %try and the load in %catch. mem2reg wants to eliminate %x and replace the load in %catch with a fixed value. This involves looking at the value stored in %x at all predecessor points, which is a challenge because one of those

On Feb 10, 2010, at 8:57 AM, Sanjiv Gupta wrote: > Chris Lattner wrote: >> On Feb 9, 2010, at 7:39 PM, Sanjiv Gupta wrote: >> >> >>> Hi, >>> I need to add switches like -disable-mem2reg, disable-gvn to llvm-ld. >>> Currently CreateStandardLTOPasses takes in only DisableInternalize and >>> DisableInliner switches. >>>

We can let compiler driver pass the right options to preprocessor after processing -Mxy options, right now its bypassing the gcc driver and handing them straight to cpp This also helps in other compilers processing these options correctly for their preprocessors consumption Signed-off-by: Khem Raj <raj.khem at gmail.com> --- mk/syslinux.mk | 4 ++-- 1 file changed, 2 insertions(+), 2

On Nov 28, 2010, at 3:47 PM, John McCall wrote: > So mem2reg would have to split %try and make a phi in %lp, like so: > > try1: unwinds to %lp > %count = load i32* @count > br label %try2 > try2: unwinds to %lp > call void foo() > br label %return > lp: > %t = phi i32 [ i32 0, label %try1 ], [ i32 %count, label %try2 ] > #etc. > > That's a lot of