similar to: [LLVMdev] First-class debug info IR: MDLocation

> On 2014-Oct-27, at 00:58, Chandler Carruth <chandlerc at google.com> wrote: > > I haven't been able to follow all of the thread that got us here but your patch below has distilled the result enough for me to at least ask questions. Always takes a patch to draw people in :). > I'm sorry of some of the justification is buried in the thread and I'm just making you

After splitting `Metadata` apart from `Value`, I'm finally back to the first step [1] of representing debug info more directly in IR [2]: `MDLocation`. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078173.html "First-class debug info IR: MDLocation" [2]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html "Less memory and greater

I suspect it would actually be *better* if I got all this in before the branch, since it'll make cherry-picking testcases easier. However, these patches themselves (and I suspect a few more prep commits) don't actually move `MDLocation` into place -- it's not until then that all the testcase updates have to happen. I'm not convinced that (monster) commit will land by tomorrow :(.

Hi Paul, I'm not sure I see any reason to wait until after 3.6. More changes are incoming and it's better to get them over with sooner rather than spread out the pain. Thanks! -eric On Mon Jan 12 2015 at 9:52:48 PM Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Would you mind terribly waiting a week, until after 3.6 is forked? > > We're barely

> On 2015-Jan-14, at 11:26, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 14, 2015, at 11:12 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: >> One small request: Omitting the column field from MDLocation if it is 0 is fine,

> On 2015 Jan 13, at 11:13, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > >> I suspect it would actually be *better* if I got all this in before >> the branch, since it'll make cherry-picking testcases easier. > > Excellent point, go for it. I missed the branch deadline, but I merged it in as of r226095. > --paulr > >> >>

On Wed, Jan 14, 2015 at 11:04 AM, Adrian Prantl <aprantl at apple.com> wrote: > One small request: Omitting the column field from MDLocation if it is 0 is > fine, because it won’t make it into the line table. Omitting the line if it > is 0 is not, because it gives the wrong impression that the line is being > ignored, which is not the case. Line 0 will be emitted in the line

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,

On Wed, Oct 15, 2014 at 8:53 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > As all of these transforms are 1-to-1, can we still support the older metadata and convert it on the fly? > I'd prefer not to keep all of that code around to interpret both versions without a very good reason. -eric > Alex > >> On Oct 13, 2014, at 3:02 PM, Duncan P. N. Exon Smith

On Mon, Oct 13, 2014 at 7:01 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon, Oct 13, 2014 at 6:59 PM, Sean Silva <chisophugis at gmail.com> wrote: > > For those interested, I've attached some pie charts based on Duncan's > data > > in one of the other posts; successive slides break down the usage > > increasingly finely. To my

For those interested, I've attached some pie charts based on Duncan's data in one of the other posts; successive slides break down the usage increasingly finely. To my understanding, they represent the number of Value's (and subclasses) allocated. On Mon, Oct 13, 2014 at 3:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > In r219010, I merged integer and

Hi Folks, I ran into this assertion failure while compiling a function with a large number of arguments: https://llvm.org/bugs/show_bug.cgi?id=21609 I have coded up the fix as per David's suggestion (added a new header field for DIVariable to separate out ArgNo & LineNo). The proposed diff is attached to the bug. However, there are around 175 testcases across clang & llvm that need

Hi- Here is the simple C++ function: ----------- void foo() { } ----------- Let's say, above function is compiled to generate LLVM IR with -g flag using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get below IR ----------- ; ModuleID = 'foo.cpp' source_filename = "foo.cpp" target datalayout =

I just reported this bug: https://bugs.llvm.org/show_bug.cgi?id=35314 This very simple IR is causing infinite recursion in llvm::DwarfUnit::getOrCreateTypeDIE in llvm 5.0.0. Is there a workaround? Is anyone willing to save me a recompile and check if this is fixed in 5.0.1 or trunk? `clang -c test.ll` repros the issue. ; ModuleID = 'test' source_filename = "test" target

On Tue, Apr 28, 2015 at 7:14 PM, David Blaikie <dblaikie at gmail.com> wrote: > I believe duncan's fixed this recently in 235956 and 235955 - does ToT work > for you? It seems like r235955 might have fixed it. However I'm having build issues with ToT in my environment. Is this the right place to check ToT build status: http://lab.llvm.org:8011/one_line_per_build > > On

Hi David If you look at line https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160 there is IR verification which asserts that only in case of `spFlags = DISPFlagDefinition`, the compilation unit (`unit` field) should be present. Otherwise, it should *not* be present. In the crash case, `spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be present,

On 15 January 2015 at 13:35, Renato Golin <renato.golin at linaro.org> wrote: > AArch64 tested and uploaded. ARMv7 in progress. Hi Hans, ARMv7 is giving me a bit of a headache... I've tried building on two different machines and I get the same error... Phase 2 completes successfully, but while building Phase 3, I get the error on *every* file: 1.

I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`, so, `unit` must be present for `optimized ` too. Am I right? Mahesha On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote: > definition and optimized are orthogonal (a function could be both, or > neither) - one says this DISubprogram describes a function

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