search for: ctmark

...>>> I also haven't measure the impact on compile time. >> >> Do you have a mean to make this measurement? >> Ahmed did a bunch of compile time measurements on our side and I wanted to see if I need to put him on the hook again :). > > I did a quick setup with CTMark (part of the test-suite). I ran each of > * '-O0 -g', > * '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0', and > * '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0 -mllvm -optimize-regalloc -mllvm -regalloc=greedy' > 5 times, cross-compi...

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

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

...try to squeeze as much performance as possible, but it is too excessive for other opt-levels. InstCombine has an ExpensiveCombines parameter to address that - but I think it's underused at the moment. Trying to find out, which patterns are important, and which are rare, I profiled clang using CTMark and got the following coverage report: (beware, the file is ~6MB). Guided by this profile I moved some patterns under the "if (ExpensiveCombines)" check, which expectedly happened to be neutral for runtime performance, but improved compile-time. The testing results are below (measured f...

...e 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 out of 10 “long” compiling tests of the LLVM test suite and track it closely for ARM64 O0g and Os. When there is a jump in compile-time of more than 2.5% in one of the tests an email notification will be sent to the committer and a bug will be filed in bugzilla. The 2.5% threshold is large en...

...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 meantime! > > I’d like to suggest adding to CTMark the “empty” compile test (and maybe “empty + one empty function”), unless it is too noisy to measure. > It is an interesting test to complete the existing ones because it measures the general overhead of setting up all the “infrastructure” (static initializers, creating a pass pipeline, etc.) Th...

...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 compared to January compiler. I remeasured compile time data for CTMark tests and annotated the biggest changes, the graphs for Os and O0-g are attached below. Thick black line represents geomean, colored thin lines represent individual tests. The data is normalized on the first revision in the range (which is ~Jun, 2015). *** Future work *** There are still plenty of...

> 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 suite. This assertion is supposed to get evaluated (and the benchmarks in CTMark possibly adjusted) on a regular basis which should happen rou...

...the impact on compile time. >>>> >>>> Do you have a mean to make this measurement? >>>> Ahmed did a bunch of compile time measurements on our side and I wanted to see if I need to put him on the hook again :). >>> >>> I did a quick setup with CTMark (part of the test-suite). I ran each of >>> * '-O0 -g', >>> * '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0', and >>> * '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0 -mllvm -optimize-regalloc -mllvm -regalloc=greedy' &...

...f time in ValueTracking (getting known bits and similar)? -Hal > > CC: David for the general direction on InstCombine though. > > > — > Mehdi > > > >> >> Trying to find out, which patterns are important, and which are rare, >> I profiled clang using CTMark and got the following coverage report: >> <InstCombine_covreport.html> >> (beware, the file is ~6MB). >> >> Guided by this profile I moved some patterns under the "if >> (ExpensiveCombines)" check, which expectedly happened to be neutral >> for...

...> -Hal > > >> >> CC: David for the general direction on InstCombine though. >> >> >> — >> Mehdi >> >> >> >>> >>> Trying to find out, which patterns are important, and which are rare, I profiled clang using CTMark and got the following coverage report: >>> <InstCombine_covreport.html> >>> (beware, the file is ~6MB). >>> >>> Guided by this profile I moved some patterns under the "if (ExpensiveCombines)" check, which expectedly happened to be neutral for run...

...> -Hal > > >> >> CC: David for the general direction on InstCombine though. >> >> >> — >> Mehdi >> >> >> >>> >>> Trying to find out, which patterns are important, and which are rare, I profiled clang using CTMark and got the following coverage report: >>> <InstCombine_covreport.html> >>> (beware, the file is ~6MB). >>> >>> Guided by this profile I moved some patterns under the "if (ExpensiveCombines)" check, which expectedly happened to be neutral for run...

...gt;> -Hal >> >> >> >> CC: David for the general direction on InstCombine though. >> >> >> — >> Mehdi >> >> >> >> >> Trying to find out, which patterns are important, and which are rare, I >> profiled clang using CTMark and got the following coverage report: >> <InstCombine_covreport.html> >> (beware, the file is ~6MB). >> >> Guided by this profile I moved some patterns under the "if >> (ExpensiveCombines)" check, which expectedly happened to be neutral for >> ru...

Can you post numbers for how many stores get eliminated from CTMark? > On Apr 16, 2019, at 11:45 AM, Vitaly Buka <vitalybuka at google.com> wrote: > > I tried -Os and effect of new approach significantly increases. > I run regular DSE and immediately myDSE. With -Os myDSE removes more than 50% of DSE number. > Which is expected as -Os inlines...

> On May 10, 2019, at 8:59 PM, Vitaly Buka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry for delay, I was busy with other stuff. > CTMark results. > > dse is the current DSE. > dsem is my experimental module level DSE. > dsem runs after dse, so it's additionally deleted stores. > > -O3 > dse - Number of stores deleted 3033 > dsem - Number of deleted writes...

...à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > >> On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at apple.com> wrote: >>> >>> Latest comparisons on my side, after picking up r304244, i.e. the correct Localizer pass. >>> * CTMark compile time, comparing "-O0 -g" vs '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0': about 6% increase with globalisel. This was about 3.5% before the Localizer pass landed. >> >> That one is surprising too. I wouldn’t have expected this pass to show up...

...> Le 1 juin 2017 à 07:46, Kristof Beyls <Kristof.Beyls at arm.com> a écrit : > > > On 31 May 2017, at 17:07, Quentin Colombet <qcolombet at apple.com> wrote: > > > Latest comparisons on my side, after picking up r304244, i.e. the correct > Localizer pass. > * CTMark compile time, comparing "-O0 -g" vs '-O0 -g -mllvm > -global-isel=true -mllvm -global-isel-abort=0': about 6% increase with > globalisel. This was about 3.5% before the Localizer pass landed. > > > That one is surprising too. I wouldn’t have expected this pass to sh...

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 Use and User. Any thought? Cheers, Gauthier -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pi...

...e: >> >> Cool test :) >> It seems to work fine now, I don't see any new failures. IIUC, Kristof is also giving it another run. >> >> Cheers, >> Diana > > Latest comparisons on my side, after picking up r304244, i.e. the correct Localizer pass. > * CTMark compile time, comparing "-O0 -g" vs '-O0 -g -mllvm -global-isel=true -mllvm -global-isel-abort=0': about 6% increase with globalisel. This was about 3.5% before the Localizer pass landed. That one is surprising too. I wouldn’t have expected this pass to show up in the compile tim...

...experimented with following DSE improvements: > > > > * Cross-block DSE, it eliminates additional 7% stores comparing to existing DSE. But it's not visible on benchmarks. > I take it you couldn’t see any runtime impact? If there’s code size improvements that could also be useful, CTMark in the llvm test suite is a useful subset of benchmarks to check this on (as a baseline use -Os to compare code size). > > Thanks, > Amara > > > > * Cross-block + Interprocedural analysis to annotate each function argument with: > > - can read before write > > -...