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

Displaying 20 results from an estimated 1000 matches similar to: "[SelectionDAG] DbgValue nodes aren't transferred"

2018 Mar 13
2
[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
2018 Mar 14
2
[SelectionDAG] DbgValue nodes aren't transferred
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
2018 Mar 09
0
[SelectionDAG] DbgValue nodes aren't transferred
+ 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
2018 Mar 14
0
[SelectionDAG] DbgValue nodes aren't transferred
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
2018 Mar 15
1
[SelectionDAG] DbgValue nodes aren't transferred
> 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
2018 Apr 30
0
[SelectionDAG] DbgValue nodes aren't transferred
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
2018 Apr 30
2
[SelectionDAG] DbgValue nodes aren't transferred
> 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 >
2018 Apr 30
0
[SelectionDAG] DbgValue nodes aren't transferred
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]
2018 Mar 09
0
[SelectionDAG] DbgValue nodes aren't transferred
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,
2018 Apr 30
2
[SelectionDAG] DbgValue nodes aren't transferred
> 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:
2018 Apr 30
1
[SelectionDAG] DbgValue nodes aren't transferred
> 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
2018 Apr 30
0
[SelectionDAG] DbgValue nodes aren't transferred
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
2014 Sep 18
2
[LLVMdev] troubles with ISD::FPOWI
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
2011 Apr 15
2
[LLVMdev] Valid debug information being deleted by DAGCombiner
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
2011 Apr 15
0
[LLVMdev] Valid debug information being deleted by DAGCombiner
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
2015 Jun 23
4
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
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
2012 Mar 08
2
[LLVMdev] A question about DBG_VALUE and Frame Index
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
2020 Feb 24
5
[RFC] DebugInfo: A different way of specifying variable locations post-isel
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
2011 Oct 10
2
[LLVMdev] Expected behavior of eliminateFrameIndex() on dbg_value machine instructions
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
2011 Oct 11
1
[LLVMdev] Expected behavior of eliminateFrameIndex() on dbg_value machine instructions
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. >