similar to: [LLVMdev] Looking for a fix to memory leak in DWARF support

David, Thanks for the quick response... No, at this point I am just getting into the issue... I assume it is a leak, but no clear proof yet. I was hoping it was an obvious thing since I recall a discussion about it a while ago... but maybe I am just confused. Was your work for compressing DWARF data motivated by a certain inefficiency in debug info representation? Did it result in

Thanks Eric, They are doing LTO build but with some custom modifications (think a library at a time as opposed to a whole program). I must admit, it is a rather large application as well, so as expected, any inefficiencies are multiplied greatly. >From little that I have seen so far, it looks like debug metadata for an IR object linger behind once the object itself is eliminated (optimized).

Eric, Let me clarify it a bit... without type uniqueing for LTO + debug will I have a highly inefficient IR representation or incorrect debug info? If debug info for LTO is known to be non-useful or ambiguous or flat wrong - there is no point in fixing its emission... or will it still be practical and if I manage to improve it somewhat the customer will still have some value-add by using it?

On Aug 9, 2012, at 10:09 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Yang, > > This might not be such a tough choice on engineering side - one of the > LLVM differentiators is the ground-up, early introduced support for VLIW > specific features… Actually, LLVM lacked support for VLIW until fairly recently, and it has relatively few VLIW-specific features. Dan

Chris, Thanks for the clarification... at least no bug report is due... and I am glad that I've asked. In my case these transformations are rather useful and forcing them to copy original global variable section is making them compatible with our (rather important) use case, so I guess I will have to fix it locally. Nevertheless if someone else would have a similar issue - I would be

Hi Sergei. If an instruction conditionally writes R0 then I think it needs to implicitly use R0 for proper liveness Andy On Aug 9, 2012, at 9:48 AM, Sergei Larin <slarin at codeaurora.org> wrote: > > Hello everyone, > > Let me (re)present a question that might have previously been discussed, > but did not result in any code (AFIK). > > How do we represent a

In general I use DebugInfoFinder and clear out Metadata if GV in null or GV->isDeclaration(). If there is any interest, I can post that patch... Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Tobias Edler von Koch [mailto:tobias at codeaurora.org] > Sent: Friday, February 12, 2016

But we are really striving to change it fast :) Dan, My comparative point was that LLVM has a greater potential to accommodate VLIW going forward than GCC does at this point. Would you agree to that? Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: Dan Gohman [mailto:gohman at apple.com] > Sent: Friday, August 10,

I was just going to say: With well-formed debug info it should create a deep copy up until the DISubprogram, but no further. But because the DISubprogram linked to the Function is missing the special handling of the DISubprogram (that would prohibit cloning the DICompileUnit is side-stepped). But then I remembered the discussion we had in

On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Generally as far as I concern, there is no way “generic” (platform independent) code can add instructions to bundles optimally I agree, there are too many ways of modeling stuff with bundles. That is why I took the philosophical stance of treating bundles as black boxes during RA. I think the

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize

Larin, Thank you for telling me about this. Our lab is planning to design a VLIW DSP and has to make a choice between GCC and LLVM, for which I take responsibility. As we all know that GCC's codes possess a long history and has a somewhat bad learning curve, I suggest choosing LLVM. It seems now the only drawback is its poor support for VLIW architecture. And so if we can count on

Andy, Yes, this is what Arnold has suggested also, and from this point it looks like it should work, but it will require parsing the bundle every time we care to know whether this is a real use or a conditional def. This might become awkward... but I guess I should provide a better use case to prove my point. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >

Peter, I am afraid I am missing a big picture with debug info cloning. Certainly after your patch (and possibly in some cases earlier): Cloning: Reduce complexity of debug info cloning and fix correctness issue. Commit r260791 contained an error in that it would introduce a cross-module reference in the old module. It also introduced O(N^2) complexity in the

Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)...

Hi Sergei, Jakob, Thanks for your comments ! On 07/06/2012 20:41, Sergei Larin wrote: > > Jakob, > > Please see my comments below. Hope this helps. > > Sergei > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei

Hi Lang, Just one more quick question. in LiveIntervalAnalysis.cpp In SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) Did you really mean to use for (MachineRegisterInfo::use_nodbg_iterator UI = MRI.use_nodbg_begin(Reg), UE = MRI.use_nodbg_end(); UI != UE; UI.skipInstruction()) {} Aren't we currently dealing with units,

Hi Sergei, "addRuntimeCheck" inserts code that checks that two or more arrays are disjoint. I looked at the code and it looks fine. We generate PHIs in the order that they appear in a vector. The values are inserted in 'canVectorizeMemory', which also looks fine. Please let me know if you think I missed something. Thanks, Nadav On Jan 29, 2013, at 8:48 AM, Sergei Larin

Eli, When you say "include tests" what exactly do you mean - ability to run newly produced binary on newly supported target? Can you please elaborate? Thanks. Sergei Larin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, November 01, 2011 1:58 PM To: Tony Linthicum Cc: llvmdev at