Currently LLVM releases, as downloaded from llvm.org, have assertions enabled. (I'm told Apple ships LLVM with assertions disabled, which is why I mention llvm.org here). What do people think of disabling assertions? The advantage of disabling assertions is that LLVM runs faster. I don't know how much faster. It also makes for fairer comparisons with gcc releases, which have all but the cheapest checks disabled. The disadvantage of disabling assertions is that we get less information in bug reports. An additional consideration here is clang: while LLVM itself is reasonably mature, that's not the case for clang. I don't know if it is practical to ship LLVM with assertions disabled, and clang with assertions enabled. A different possibility is to analyse which checks are the most expensive, and just disable those. Thoughts? Ciao, Duncan.
On 06/20/2010 11:11 PM, Duncan Sands wrote:> Currently LLVM releases, as downloaded from llvm.org, have assertions enabled. > (I'm told Apple ships LLVM with assertions disabled, which is why I mention > llvm.org here). What do people think of disabling assertions? > > The advantage of disabling assertions is that LLVM runs faster. I don't know > how much faster. It also makes for fairer comparisons with gcc releases, which > have all but the cheapest checks disabled. > > The disadvantage of disabling assertions is that we get less information in bug > reports. > > An additional consideration here is clang: while LLVM itself is reasonably > mature, that's not the case for clang. I don't know if it is practical to > ship LLVM with assertions disabled, and clang with assertions enabled. > > A different possibility is to analyse which checks are the most expensive, > and just disable those. > > Thoughts?I am running with assertions enabled and it was very useful in finding bugs on platforms I can't (or rarely) test on. Had assertions been off I think bad/invalid code would have been generated silently, resulting in a much harder to debug segfault. There are certain assertions that shouldn't be disabled IMHO. Like those in codegen that check for "impossible" conditions, or conditions under which codegen can't continue. For example the assertions about relocations being in bounds on PowerPC. Perhaps these shouldn't be assertions at all, but there are far too many asserts to go over them one-by-one now and decide on converting to llvm_error. Maybe we should convert the "cheap" (invoked once per instruction at most) assert checks to something else, and then you could turn off the rest of the assertions. Best regards, --Edwin
Joachim Durchholz
2010-Jun-20 21:03 UTC
[LLVMdev] Disabling assertions in llvm.org releases
Török Edwin schrieb:> Had assertions been off I think bad/invalid code would have been > generated silently, resulting in a much harder to debug segfault.Just a thought: how about distributing a "production build" with only the most important assertions active, and a "diagnostic build" that has all assertion checking on? In that case, if there's "funny behaviour" in the generated code, people can be instructed to try running their code through diagnostic build and see whether it assertion checks. Or they could be told to use the diagnostic LLVM when building production code just to be sure, but normally, the standard build will suffice. Regards, Jo
On 20 June 2010 21:11, Duncan Sands <baldrick at free.fr> wrote:> An additional consideration here is clang: while LLVM itself is reasonably > mature, that's not the case for clang. I don't know if it is practical to > ship LLVM with assertions disabled, and clang with assertions enabled.I strongly suggest not to. LLVM's assertions won't only get LLVM's own bugs, but also Clang bugs. IR is not perfect and sometimes allow wrong code to be produced and validated, only to break at codegen pass on an assert. As they're a last resort in finding problems, I fear that if we turn them off, bad code will be generated and, as they'll be running on the user, it'll be very difficult to trace or even find out that there is a bug in the compiler in the first place. Maybe what we need is a cheaper error check. Less computation on the checking and more on the reporting, so only if there is an error, the red button is pressed. So, instead of: assert(condition && "error message"); we do: if (!condition) error("message"); I don't think it's that much difference, but that's the cheaper I can think of... cheers, --renato PS: asserts get inlined normally, don't they?
Hi Torok,> I am running with assertions enabled and it was very useful in finding > bugs on platforms I can't (or rarely) test on. > Had assertions been off I think bad/invalid code would have been > generated silently, resulting in a much harder to debug segfault.are you using the binaries supplied by llvm.org, or building yourself? There is a big difference between what is useful for developers (i.e. helpful back traces etc) and what is useful for users (i.e. speed). Since developers typically build LLVM themselves, they can always turn assertions on. Ciao, Duncan.
Apparently Analagous Threads
- [LLVMdev] Disabling assertions in llvm.org releases
- [LLVMdev] Disabling assertions in llvm.org releases
- [LLVMdev] Disabling assertions in llvm.org releases
- [LLVMdev] Disabling assertions in llvm.org releases
- [LLVMdev] Disabling assertions in llvm.org releases