search for: waymark

Hi llvm-dev, I have a patch open for review that removes waymarking https://reviews.llvm.org/D77144. This patch removes waymarking and replaces it with storing a pointer to the User in the Use. when compiling the CTMark tests of the test suite, this give an average of +1.8% max memory use and -1.1% compile time. Removing Waymarking also simplifies the code of...

...e worst case, 336 MB more memory spent on compilation. 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 can't prove the Waymarking was needed at all. On Thu, Apr 2, 2020 at 8:10 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Apr 1, 2020, at 5:51 AM, Tyker1 at outlook.com via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hi llvm-dev, > > I have a patch open...

...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: <http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/waymark-64-new/> I do not have the equipment to perform a compile-time measurement. How do folks benchmark for this nowadays? Is it a viable alternative to bring the changes to ToT and compare speedups/slowdowns in the nightly builds retrospectively? Thanks for any input, cheers, Gabor (*) Some...

...>> >> 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 can't prove the Waymarking was needed at all. > I guess if no-one brings forth arguments (= results) for keeping it and > > people continue to support replacing it, we will replace it. There should > > be a grace period in which people have the chance to do their benchmarking > > (basically what is...

...2020 7:40 PM > *To:* Johannes Doerfert <johannesdoerfert at gmail.com> > *Cc:* Ehud Katz <ehudkatz at gmail.com>; llvm-dev at lists.llvm.org < > llvm-dev at lists.llvm.org>; Tyker1 at outlook.com <Tyker1 at outlook.com> > *Subject:* Re: [llvm-dev] [RFC] Removing Waymarking from Use. > > > > 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...

...; 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: >> <http://llvm.org/viewvc/llvm-project/llvm/branches/ggreif/waymark-64-new/> >> >> I do not have the equipment to perform a compile-time measurement. How >> do folks benchmark for this nowadays? Is it a viable alternative to >> bring the changes to ToT and compare speedups/slowdowns in the nightly >> builds retrospectively? > &gt...

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

On 09/21/2018 01:30 PM, Chris Lattner via llvm-dev wrote: On Sep 19, 2018, at 1:30 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi folks, I looked into some slow compiles and filed https://bugs.llvm.org/show_bug.cgi?id=38829. The gist of it is that we spend a lot of time iterating basic blocks to compute local dominance, i.e.