similar to: [LLVMdev] Debug info for lazy variables triggers SROA assertion

On Tue, Jan 5, 2016 at 6:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > Thanks for the clarification, Paul! > Keno, just a few more questions for my understanding: > > > - Indicating that a value changed at source level (e.g. because an > > assignment occurred) > > This is done by a key call. Correct > > - Indicating that the same

I will be out of the office on January 7th and will return on January 19th. I will not have access to email during this time. Please contact Karen Lavelle at klavelle at rice.edu or 713-348-2062 if you have any questions or concerns. Best regards, Annepha On Jan 6, 2016, at 3:58 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jan 5, 2016, at 10:37 AM,

Adrian had proposed the following staging: 1. Remove offset argument from dbg.value 2. Unify dbg.value and dbg.declare 3. Full implementation I'm not yet sure what to do about the difference in dbg.declare semantics. For example, i think the following currently works ``` top: %x = alloca br else if: dbg.declare(%x... unreachable else: # dbg.declare still applies here ``` I think it would

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

I want to emit a ref parameter (ie i32*) as if it was i32 in debug info, however when I emit it with llvm.debug.declare referring to the parameter register it shows the actual pointer value of the debug register, instead of the value it refers to. This works fine if the llvm.debug.declare points to a local alloca, how can this be and how can I make it work so both show the integer value

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

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

Thanks for your comments. Replies inline. > The DWARF 5 standard says that > "Address range entries in a range list may not overlap.” > > The reasoning behind this is presumably that if a variable is in more than > one > location at a point all the values need to be identical, or the > information is useless Oh huh, for some reason I was under the impression that they

Hey folks, Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can

Could you provide the complete example (with all the necessary metadata to reproduce)? Possible LLVM has a special case for arguments, I'm not sure/don't recall off hand, but can poke around at it & see if there's a reasonable logic to it. On Tue, Dec 20, 2016 at 10:43 PM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I want to emit a ref parameter (ie

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg