search for: expensive_check

Hi folks, In case you missed it and care about the speed of builds with EXPENSIVE_CHECKS enabled: they should get noticeably faster after r323298. Before the patch, building the llvm test suite took 51m 42s, and after the patch it got down to 39m 7s (measured on 2x Intel E5-2690). The patch introduced 3 DomTree verification levels (Fast, Basic, Full) to make the expensive checks mor...

Hello, I'm trying to run checks with EXPENSIVE_CHECKS enabled, but it crashes when generating some intrinsics file with TableGen. > cd /home/luke/Source/llvm-project/build && /home/luke/Source/llvm- > project/build/bin/llvm-tblgen -gen-intrinsic-impl -I /home/luke/Source/llvm- > project/llvm/include/llvm/IR -I /home/luke/Source/llv...

Hi David, Unfortunately writing a reliable test is tricky given that the functionality we're trying to test involves timing. I would advise against disabling the test entirely because it actually tests functionality that people use. I'd suggest bumping up the time limits. This is what I've done in the past. See commit 6dfcc78364fa3e8104d6e6634733863eb0bf4be8 Author: Dan Liew <dan

...haven't needed to touch the code or tests since 2018. I haven't been asked to review any patches related to the timeout feature since then so I presume nobody has touched it since. > Another option might be to reduce how often/in which configurations > the test is run - LLVM_ENABLE_EXPENSIVE_CHECKS presumably only works > for code within LLVM itself, and not test cases - but maybe I'm wrong > there & this parameter could be used (& then the timing bumped up > quite a bit to try to make it much more reliable), or something > similar could be implemented at the lit chec...

...ion[0], whenever an LLVM pass doesn't modify the IR it's run on, it should return `false`--it's okay to return `true` if no change happen, just less optimal. In the New PM area, this is generally translated into a `PreservedAnalyses::all()`. https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that computes a hash of the IR before and after the pass, and checks that any change is correctly reported. The hash is currently incomplete (on purpose, let's start small), but it turns out a dozen of passes do not satisfy that requirement. This could lead to various category of bugs (dangli...

...wn (i.e., 6.28s to 3443.83s) for one of the files > from SPEC2017/blender.  The issue arises only in debug builds due to > the numerous calls to RefSCC::verify() and SCC::verify() in the > LazyCallGraph implementation.  Would it make sense to start > predicating these calls with the EXPENSIVE_CHECKS macro, rather than > NDEBUG? > >  Chad > > > On 10/18/2017 2:50 AM, Chandler Carruth via llvm-dev wrote: >> Greetings everyone! >> >> The new pass manager is getting extremely close to the point where >> I'm not aware of any significant outstanding w...

...t; it's run on, it >> should return `false`--it's okay to return `true` if no change happen, >> just less >> optimal. In the New PM area, this is generally translated into a >> `PreservedAnalyses::all()`. >> >> https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that >> computes a >> hash of the IR before and after the pass, and checks that any change is >> correctly reported. The hash is currently incomplete (on purpose, let's >> start >> small), but it turns out a dozen of passes do not satisfy that >> requirement...

Thanks for noticing this, Geoff. I just landed r268050 which add a cmake option for this (and unifies XDEBUG and EXPENSIVE_CHECKS). This might make it easier to setup some build bots. Thank you, Filipe On Fri, Apr 22, 2016 at 8:40 PM, Geoff Berry via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Bugs filed: > 27488 <https://llvm.org/bugs/show_bug.cgi?id=27488> librarie Scalar O > unassignedbugs a...

...gt;>> should return `false`--it's okay to return `true` if no change happen, >>> just less >>> optimal. In the New PM area, this is generally translated into a >>> `PreservedAnalyses::all()`. >>> >>> https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that >>> computes a >>> hash of the IR before and after the pass, and checks that any change is >>> correctly reported. The hash is currently incomplete (on purpose, let's >>> start >>> small), but it turns out a dozen of passes do not satisfy that...

r327219 added a new wrapper function called *llvm::sort*. If EXPENSIVE_CHECKS is enabled, llvm::sort will randomly shuffle the container before invoking std::sort. This will help uncover non-deterministic ordering of objects having the same key. All occurrences of std::sort have been changed to llvm::sort in llvm/clang/polly repos. Going forward please make sure to avo...

...one entry per module). Having every module's Debug/bin in PATH and Debug/lib in LD_LIBRARY_PATH gets hard to maintain when there's multiple environments. Furthermore, the paths need to change when you switch to a release or release+asserts or release +expensive_checks build. * There are inter-dependencies between modules which may affect the relative ordering of the PATH and LD_LIBRARY_PATH component paths. * Building things can be affected because if you put the wrong directory in your LD_LIBRARY_PATH you can end up linking...

...#39; DATE='' DEBUG_RUNTIME='' DEFS='' DISABLE_ASSERTIONS='' DOT='' DOTTY='' DOXYGEN='' ECHO='echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ENABLE_CBE_PRINTF_A='' ENABLE_DOXYGEN='' ENABLE_EXPENSIVE_CHECKS='' ENABLE_OPTIMIZED='' ENABLE_PIC='' ENABLE_THREADS='' ENABLE_VISIBILITY_INLINES_HIDDEN='' ENDIAN='' EXEEXT='' EXPENSIVE_CHECKS='' EXTRA_OPTIONS='' F77='' FFLAGS='' FIND='' FLEX='' GAS=''...

...-April/013536.html) of the design principles of the ncurses-based LLDB 'GUI', as well as things he would like to see changed. * Mandeep Singh Grang [reports](http://lists.llvm.org/pipermail/llvm-dev/2018-April/122576.html) that a new llvm::sort wrapper function has been introduced. For an `EXPENSIVE_CHECKS` build this will randomly shuffle the container before sorting, which helps to uncover non-deterministic sorting of objects with the same key. * Katya Romanova has started a [discussion](http://lists.llvm.org/pipermail/llvm-dev/2018-April/122469.html) on unifying the bitcode file generation phase...

...me. Regardless of the users PATH setting, the build process for the various modules should invoke the tools from other modules *without* PATH needing to be set. > Furthermore, the paths need to change > when you switch to a release or release+asserts or release > +expensive_checks build. We have this problem today, it isn't a significant issue AFAICT. > * There are inter-dependencies between modules which may affect > the relative ordering of the PATH and LD_LIBRARY_PATH component > paths. This is only an issue if you have a name collision...

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object...

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

...IteratorConcept<_ForwardIterator>) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > On Tue, Sep 3, 2019 at 7:10 AM Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with >> EXPENSIVE_CHECKS enabled and running into various errors compiling >> SourceMgr.cpp, depending on which host compiler I use. >> >> For example with GCC: >> >> $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug >> -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm...

...; > DISABLE_ASSERTIONS='' > DOT='' > DOTTY='' > DOXYGEN='' > ECHO='echo' > ECHO_C='' > ECHO_N='-n' > ECHO_T='' > EGREP='' > ENABLE_CBE_PRINTF_A='' > ENABLE_DOXYGEN='' > ENABLE_EXPENSIVE_CHECKS='' > ENABLE_OPTIMIZED='' > ENABLE_PIC='' > ENABLE_THREADS='' > ENABLE_VISIBILITY_INLINES_HIDDEN='' > ENDIAN='' > EXEEXT='' > EXPENSIVE_CHECKS='' > EXTRA_OPTIONS='' > F77='' > FFLAGS='&...

...~~~~~~~~~~~~~~~~~ >> > >> > On Tue, Sep 3, 2019 at 7:10 AM Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Hi, >> >> >> >> I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with >> >> EXPENSIVE_CHECKS enabled and running into various errors compiling >> >> SourceMgr.cpp, depending on which host compiler I use. >> >> >> >> For example with GCC: >> >> >> >> $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug >> >> -DL...

...PATH > needing to be set. Yeah, its more LD_LIBRARY_PATH that I'm concerned about. It can and does screw up linking if its set wrong. > > > Furthermore, the paths need to change > > when you switch to a release or release+asserts or release > > +expensive_checks build. > > We have this problem today, it isn't a significant issue AFAICT. > > > * There are inter-dependencies between modules which may affect > > the relative ordering of the PATH and LD_LIBRARY_PATH component > > paths. > > This is on...