similar to: [LLVMdev] %noreg in DBG_VALUE

Hi Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, >

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

Hi Vishal, Ruijie, Thanks for your interest in the project. To get started, the first task would be to merge the 5 patches on top of trunk llvm. The list of patches are listed in the project description: http://llvm.org/OpenProjects.html#llvm_mergesim Please create an account in llvm phabricator (reviews.llvm.org) if you haven't already, and put your patches there. Let me know if you have

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

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

Since updating to the LLVM v5.0 Final tag, I am seeing a crash when I enable '-g'. With a Debug build this hits an assertion at line #923 in 'lib/CodeGen/AsmPrinter/DwarfDebug.cpp': assert(EndLabel && "Forgot label after instruction ending a range!"); The values of related variables at this time are: 'Begin' is: DBG_VALUE %I23, %noreg,

Hi Stefanos, Thanks for your comments. I added both as reviewer. > One question though. Are you sure that this: > This helps with LICM when instructions inside a conditional is loop invariant  > is not achieved with the current LoopRotate pass? Because AFAIK, it does. Basically it inserts > a guard (that branches to the preheader) and then passes like LICM hoist invariant

Hi, I wanted to see the non-debug uses of register 0 (Noreg) and so, I wrote the following piece of code. ***** MRI = &MF.getRegInfo(); if (!MRI->use_nodbg_empty(0)) { for (MachineRegisterInfo::use_nodbg_iterator ri = MRI->use_nodbg_begin(0), re = MRI->use_nodbg_end(); ri != re; ++ri) { MachineInstr *UseMI = &*ri; UseMI->dump ();

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

> Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp. > In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end. Yes, it might not be clear but that's what I'm trying to say. Out of the non-empty DWARF locations, register and

> I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we

Here are a couple things I would try to help triangulate on the problem. Try a vanilla upstream compiler for an in-tree target. (IIRC you have your own target.) If that fails, it's pretty optimal for you because you should be able to reduce a test case and file a PR. If it doesn't fail, that suggests it's either something your target does or doesn't do, or some bug in how

On Mar 7, 2012, at 5:19 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > 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. > **************************

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

> Just chiming in about the outliner stuff. (In general, I think it's desirable to have multiple options for how early/late a pass runs.) I'm wondering if MachineOutliner can be augmented to add MachineFunctionSplitter functionalities as well. If the analysis part of MachineOutliner can allow single basic block outlining with some cost models. Aditya Kumar Compiler Engineer

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. >

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. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

Hi Nikita, Glad to hear that Rust code can benefit a lot from this. I have put patches to enable merge-similar functions with thinLTO. https://reviews.llvm.org/D52896 etc. <https://reviews.llvm.org/D52896> This is more powerful than existing merge-functions pass and all we need to do is port these patches to trunk llvm. I'd be happy to help with this effort. -Aditya

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