search for: dw_op_llvm_fragments

Hi all, I'm currently working on an out-of-tree backend and am trying to improve the debug experience when debugging optimized code. Our backend only has 8-bit and 16-bit legal types, so any larger values are expanded. The behavior I am currently seeing is that the expanded halves of an illegal type lose their debug information. Is this the expected behavior? For example, if I have an

Currently, two patches undergoing review wish to add a new operator for LLVM's DIExpression: D70642[0], and D82363[1]. Though both of these cases use the same name, the operators have different meanings: in the former, it has the form `DW_OP_LLVM_argN` where N is in [0-7], and represents the Nth argument of the containing intrinsic; its purpose is to enable the intrinsic @llvm.dbg.derefval,

Hi all, Thanks for the answers! I feel like I've hijacked your thread now though Björn, sorry for that. But from the answers it sounds like there is agreement that it's reasonable to remove the duplicates as done in Björn's patch? --- A couple of more things around the problem I saw. On 09/19/2017 05:40 PM, Adrian Prantl wrote: > A dbg.declare describes a stack-allocated

...time. Although... > Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary.

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.

> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > My understanding is that this isn't correct: dbg.declare specifies the >> memory address of a variable for the whole lifetime of the function, >> whereas dbg.value (and dbg.addr) specify the value/address until the >> next debug intrinsic. Mixing these two kinds

...> > > >> Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. > > > > This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https...

...; > >>>> Finally, to completely derail this discussion — once we have multi-arg support, we may be able to simplify parts of the debug intrinsic handling by combining multiple DW_OP_LLVM_fragment intrinsics describing the same variable into one multi-argument expression with multiple DW_OP_LLVM_fragments. > >>> > >>> This makes for a good example of how a future change might require us to support more arguments in an intrinsic than initially seems necessary. > >> > >> _______________________________________________ > >> LLVM Developers mailing list...

Thank You for suggestion Adrian! Generated reproducer for the crash using clang reproducer and CReduce. ::Attachment:: C file. NIT: some clean up is done on this file just to silent some compiler warnings(like implicit declaration etc.) Crash can be reproduced using above test case with following commandline: $clang -g -O3 -mllvm –enable-partial-inlining creducegenerated-cleaned.c -c ---CRASH---

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.