similar to: [LLVMdev] Alignment attribute of function arguments

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

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?

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

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

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

Is there a test case that you can share ? On Jan 29, 2013, at 9:24 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Nadav, > > Thanks for the quick response. By now I am convinced that the given loop > ends up vectorized with enough difference to cause bad things later on, but > I have not found the exact cause yet. To continue with my work I'll have to >

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,

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

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

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

Dave, Thank you for your interest. Please see my replies below. Sorry that my terminology is not as crisp as Andy's, but I think you can see what I mean. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: dag at cray.com [mailto:dag at cray.com] > Sent: Friday, May 11, 2012 12:14 PM > To: Sergei Larin > Cc:

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

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,

Nadav, Thanks for the quick response. By now I am convinced that the given loop ends up vectorized with enough difference to cause bad things later on, but I have not found the exact cause yet. To continue with my work I'll have to simply turn off vectorization for now, but I will come back and investigate. Again, there is some indeterminism in order of PHIs processing somewhere. I'll

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

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 Larin Cc: 'Ivan Llopard'; 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] Instruction bundles before RA: Rematerialization

Hi again! On 08/06/2012 17:11, Ivan Llopard wrote: > 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. >>

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

David, Peter, Let me try it one more time, now with an example… Short of upstreaming a fake function clone pass, let me only illustrate the issue in raw debug output. Hopefully it should be sufficient. Try this: clang -Os -g -fno-strict-aliasing test_arg_del.ll -mllvm -debug -mllvm -print-after-all After DAE - Removing argument 1 (reg) from foo DAE - Removing argument 2