similar to: [SelectionDAG] DbgValue nodes aren't transferred

Thanks for help! I think that sign extension is not involved here. PromoteIntegerResult is called since i32 is not a legal type in my target and the legalizer promotes operations with i32 result type to i64 operations. I think that SetPromotedInteger seems to be a common place for all promotions like SetExpandedInteger. Jonas, I would appreciate it if you can guide me about whether my

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

+ Adrian, Joshua + Jonas, since he contributed the transferDbgValues change in DAGTypeLegalizer::SetExpandedInteger > On Mar 8, 2018, at 5:44 PM, Se Jong Oh via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I have a problem that dbg_value nodes are not transferred when integer DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add node by

Hi Sejong, Indeed, I think you are right and we should call transferDbgValues in SetPromotedInteger. I couldn’t immediately find a suitable in-tree test to verify this though. Can you check and let me know whether this works for your target? Thanks, Jonas > On Mar 13, 2018, at 7:45 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Thanks for help! I think that sign extension

> 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

Hi Jonas, I have another case that DBG_VALUE is not produced. I would appreciate it if you could take a quick look at the testcase below. test code: llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll ; Function Attrs: nounwind ssp uwtable define void @f() #0 !dbg !4 { entry: tail call void @h(i16 0) #2, !dbg !14 %call = tail call i16 (...) @g() #2, !dbg !15 tail call void

> On Apr 30, 2018, at 1:49 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > I have another case that DBG_VALUE is not produced. I would appreciate it if you could take a quick look at the testcase below. > > > test code: > > llc -mtriple=aarch64 -stop-after=livedebugvalues -o - test.ll > > ; Function Attrs: nounwind ssp uwtable >

Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with constant. Sejong From: aprantl at apple.com <aprantl at apple.com> Sent: Monday, April 30, 2018 1:53 PM To: Se Jong Oh <sejooh at microsoft.com> Cc: jdevlieghere at apple.com; Vedant Kumar <vsk at apple.com>; llvm-dev at lists.llvm.org; pidgeot18 at gmail.com Subject: Re: [llvm-dev] [SelectionDAG]

Hi, I have a problem that dbg_value nodes are not transferred when integer DAG nodes are promoted. For example, an i32 add node is promoted to a i64 add node by DAGTypeLegalizer::PromoteIntegerResult and its dbg_value node is not transferred to the new node. t9: i32 = add nsw t5, t8 --> t31: i64 = add t30, t7 ; the dbg_value node is not transferred to the new i64 add node. For expansion,

> On Apr 30, 2018, at 2:57 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Thanks! It looks like SelectionDAG::salvageDebugInfo handles only addition with constant. You can look at llvm::salvageDebugInfo() for examples on how to handle other situations. -- adrian -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Apr 30, 2018, at 3:16 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > For cast instructions, llvm::salvageDebugInfo() simply makes dbg.value point to the source of the cast. Since SelectionDAG already has transferDbgValues which can move dbgvalue to the cast source, I think that we can just call it where the truncate is optimized away. That sounds reasonable, yes. Casts

For cast instructions, llvm::salvageDebugInfo() simply makes dbg.value point to the source of the cast. Since SelectionDAG already has transferDbgValues which can move dbgvalue to the cast source, I think that we can just call it where the truncate is optimized away. Thanks, Sejong From: aprantl at apple.com <aprantl at apple.com> Sent: Monday, April 30, 2018 2:59 PM To: Se Jong Oh

Hi, I'm stumped by how to handle fpowi. Here is the context: my architecture has i64, f32, and f64 registers. No i32. For calls & returns, we promote i32 to i64. There is no support in the architecture to perform fpowi - it has to go through the runtime. I'm using gfortran + dragonegg + llvm3.4 to generate .ll files via plugin. The fortran expression REAL = REAL ** INTEGER*4

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

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

Here is a proposal for improving DbgValueHistoryCalculator and the overall quality of debug locations. Focus: This is about lowering the DBG_VALUE machine instructions to DWARF location lists. Non-focus: This is not about (typical -O0) variables that permanently reside at a frame index and are described with dbg.declare intrinsics in the IR. These variables are stored in the MMI side-table and

Hi, I have a case that is causing me grief in the form of an assert. The prolog Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE instruction that looks like this (alongwith the Frame Index). This is for the Hexagon backend. ************************** fi#2: size=4, align=4, at location [SP-84] DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse register

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >