search for: sddbgvalu

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 ISelLowering, the vector_extract_elt instruction is lowered to a custom back...

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 apple.com] Sent: Friday, April 15, 2011 4:20 PM...

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 SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. > > During ISelLowering, the vector_extract_elt instruction is lo...

On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of

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

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

...gt; Fixing a very bad OOM condition when compiling certain programs with debug info on, plus test: > > http://llvm.org/viewvc/llvm-project?rev=221709&view=rev > > Totally forget deallocated SDNodes in SDDbgInfo. > > What would happen before that commit is that the SDDbgValues associated with > a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep > a map entry keyed by the SDNode pointer pointing to this list of invalidated > SDDbgNodes. As the memory gets reused, the list might get wrongly associated > with another new...

..., TargetConstant:i64<0>, t18:1, test.c:5:11 t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 Then, TargetLowering::LowerCallTo adds a truncate node since the function return type is i16. t21: i16 = truncate t20, test.c:5:11 When lowering the dbg.value intrinsic, a SDDbgValue node is attached to the truncate since it is the final result of the call. Lowering the third call constructs any_extend(t21) for the 32-bit register type but optimizes out the truncate node by the following code, and it seems that the DbgValue node on the truncate is also lost. SelectionDAG::g...

...:1, test.c:5:11 > t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 > > Then, TargetLowering::LowerCallTo adds a truncate node since the function return type is i16. > > t21: i16 = truncate t20, test.c:5:11 > > When lowering the dbg.value intrinsic, a SDDbgValue node is attached to the truncate since it is the final result of the call. > > Lowering the third call constructs any_extend(t21) for the 32-bit register type but optimizes out the truncate node by the following code, and it seems that the DbgValue node on the truncate is also lost. Witho...

> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do

...;, TargetConstant:i64<0>, t18:1, test.c:5:11 t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 Then, TargetLowering::LowerCallTo adds a truncate node since the function return type is i16. t21: i16 = truncate t20, test.c:5:11 When lowering the dbg.value intrinsic, a SDDbgValue node is attached to the truncate since it is the final result of the call. Lowering the third call constructs any_extend(t21) for the 32-bit register type but optimizes out the truncate node by the following code, and it seems that the DbgValue node on the truncate is also lost. Without having l...

Hi Jonas, Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. Thanks, Sejong From: jdevlieghere at apple.com <jdevlieghere at apple.com> Sent: Wednesday, March 14, 2018 4:07 AM To: Se