similar to: [RFC] Removing Waymarking from Use.

I'm in favor for this change. I've also done some testing myself and noticed only about 1-2% increase of memory, in exchange for about 1-3% increase of speed. I can't say that a speedup of 3% (at most, and usually 1%), worth working for, this is a simple change, that give a lot more than this; especially simpler code path (also easier debugging). As part of my measurements, while

Yes please. On Tue, Apr 14, 2020, 5:02 AM Tyker1 at outlook.com via llvm-dev < llvm-dev at lists.llvm.org> wrote: > a bit of time has passed and there to my knowledge still no strong > arguments against removing it. > is everyone OK to proceed with the removal ? > > Gauthier > ------------------------------ > *From:* Chris Lattner <clattner at nondot.org> >

> On Apr 3, 2020, at 11:06 AM, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > >> >> >> Is it worth it? I think it is. But I am not sure I see the whole picture - >> are there low-memory systems that need to run LLVM on? >> >> I am not sure what needs to be done to approve such a fundamental change; >> especially when we

Hi devs, after my intentionally "playful" EuroLLVM presentation (*) I think it would be time to get serious about merging to ToT. But we should probably find out whether an optimized algorithm is desired at all. So I'd solicit comments from the code owners (Use.{h,cpp}) and anybody who is interested. For closer scrutiny, the code is here:

Can you share you compile-time and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 >

Hi Kristof, Thanks for the measurements. > On May 24, 2017, at 6:00 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 23 May 2017, at 21:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Great! >> I thought I had to look at our pipeline at O0 to make sure optimized regalloc was

Great! I thought I had to look at our pipeline at O0 to make sure optimized regalloc was supported (https://bugs.llvm.org/show_bug.cgi?id=33022 <https://bugs.llvm.org/show_bug.cgi?id=33022> in mind). Glad I was wrong, it saves me some time. > On May 22, 2017, at 12:51 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > >> On 22 May 2017, at 09:09, Diana Picus

On 4/22/14, Chris Lattner <clattner at apple.com> wrote: > > On Apr 22, 2014, at 7:28 AM, Gabor Greif <ggreif at gmail.com> wrote: > >> Hi devs, >> >> after my intentionally "playful" EuroLLVM presentation (*) I think it >> would be time to get serious about merging to ToT. But we should >> probably find out whether an optimized

Did you consider using the waymarking algorithm we already use for going from Use->User to store the offset of an instruction in a basic block? We could steal the two bits needed from the bb parent pointer in the instruction. -- Sanjoy On Mon, Sep 24, 2018 at 10:20 AM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To echo what Hal said, yes, it's a major

On 10/25/2017 12:32 PM, Evgeny Astigeevich wrote: > > Hi Hal, > > I quickly checked the execution profile. It is real. The code changed > significantly. A number of the hottest regions changed. I’ll compare IRs. > Thanks. Obviously a 1000% execution performance regression seems problematic. -Hal > JFYI FreeBench/fourinarow time graph: >

Hi, One of the most time-consuming passes in LLVM middle-end is InstCombine (see e.g. [1]). It is a very powerful pass capable of doing all the crazy stuff, and new patterns are being constantly introduced there. The problem is that we often use it just as a clean-up pass: it's scheduled 6 times in the current pass pipeline, and each time it's invoked it checks all known patterns. It

> On Nov 17, 2016, at 2:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi Gerolf, > > This is really cool! > I’m very excited about this initiative and I hope we’ll be able to get to a stage where compile time regression are handled like other regression: if they are not expected / justified by the commit author promptly, the commit should be reverted in the

Hi, It's been a while since I sent the last compile time report [1], where it was shown that LLVM was getting slower over time. But now I'm happy to bring some good news: finally, LLVM is getting faster, not slower :) *** Current status *** Many areas of LLVM have been examined and improved since then: InstCombine, SCEV, APInt implementation, and that resulted in almost 10% improvement

> On Apr 11, 2017, at 10:25 PM, Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am interested in knowing more. > 1. What benchmarks does LLVM community use for compile-time study? I see CTMark, but is that the only one being analyzed? CTMark is not cast in stone. Its purpose is for the community to have a trackable proxy for the overall llvm test

Hi, this is about kicking-off regular compile-time tracking for LLVM and CLANG on the green dragon: http://lab.llvm.org:8080/green/view/Compile%20Time/ <http://lab.llvm.org:8080/green/view/Compile%20Time/>. The goal is to stay on top of compile-time issues immediately when they occur so they can be assessed rather than creeping in unnoticed. The methodology is simple: form a CTMark suite

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote: > >> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> One of the most time-consuming passes in LLVM middle-end is >> InstCombine (see e.g. [1]). It is a very powerful pass capable

> On Mar 17, 2017, at 6:12 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the

Hi Kristof, Thanks for going back so fast! > On May 24, 2017, at 12:57 PM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 24 May 2017, at 19:31, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >> Thanks for the measurements. >> >>> On May 24, 2017, at

> On Mar 17, 2017, at 6:12 PM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Honestly, I'm not a huge fan of this change as-is. The set of transforms that were added behind ExpensiveChecks seems awfully strange and many would not lead the reader to believe that they are expensive at all (the SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls

> To (hopefully) make it easier to answer this question, I've posted my (work-in-progress) patch which adds a known-bits cache to InstCombine. > I rebased it yesterday, so it should be fairly easy to apply: https://reviews.llvm.org/D31239 - Seeing what this does to the performance of the > benchmarks mentioned in this thread (among others) would certainly be interesting. Thanks! I