We might be able to reduce the size of libVMCore.a by compiling it with the -fno-exceptions flag. This prevents the compiler from generating functions that know how to propagate exceptions. VMCore is very close to being exception handling free. With a little work, we could make it exception free and turn this flag on permanently in the lib/VMCore/Makefile. Here are the outstanding issues: Pass.cpp in the constructor of FunctionPass needs to handle exceptions coming from the bytecode reader when its function is materialized. Possible solutions: 1. Don't have bytecode reader throw exceptions (big change). This actually implies that any ModuleProvider would not be able to throw exceptions. 2. Move Pass.cpp out of VMCore 3. Rearrange the code so that Pass.cpp is not the thing doing the function materialization. Verifier.cpp throws an exception when it checks abortIfBroken(). This is a feature used by the bcanalyzer and llvm-as. Both programs could be made to just abort if the verifier fails. The libraries VMCore depends upon (Support, bzip2, System) do not throw in anything that VMCore includes or calls. Since VMCore has a lot of functions, this could be a big win for library size.
I'd like to take this farther: can we eliminate exceptions from all of LLVM? The single place where they are the most useful is in libsystem, but we've already found that we don't catch the exceptions in a majority of cases. Also, traditional error handling is a well known science... -Chris
> I'd like to take this farther: can we eliminate exceptions from all of LLVM? Certain libraries (Analysis, etc.) already don't throw exceptions. We could turn on -fno-exceptions generally and then do the same hack we did for -pedantic in the individual makefiles by removing -fno-exceptions where a given library throws. > The single place where they are the most useful is in libsystem, but we've > already found that we don't catch the exceptions in a majority of cases. We have? Could you give me an example? All the tools have exception handlers in their main.
Sounds good. I don't remember the specifics, but coverity uncovered a number of them, which I fixed back then.
What's the status of this? Are we trying to remove exceptions from all of LLVM for 1.8?
Not going to happen for 1.8. Hopefully for 1.9, we're pretty close already. -Chris
I just built LLVM with -fno-exceptions turned on in LLVMCore. Everything built fine and it passed regression tests. I suppose that's not enough as the real test would be to cause an exception? Perhaps we should have some regression tests to try a couple exceptions .. say a bad file name or something.
Right. I don't see any value in trying to push to get a half-baked solution for 1.8. We might as well do it right for 1.9. -Chris
The grep tool tells me that these libraries: ./lib/AsmParser/Makefile ./lib/Bytecode/Archive/Makefile ./lib/Bytecode/Reader/Makefile ./lib/Debugger/Makefile ./lib/Support/Makefile ./lib/System/Makefile Are the only ones that remain with "REQUIRES_EH". Does anyone know if exceptions have been completely removed from any of these? We should get this cleaned up so we can eliminate EH from all the tools and finally compile llvm with -fno-exceptions.
The LLVM Assembly Parser has been rid of exceptions. These patches apply: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036852.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036853.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036854.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036855.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036856.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036857.html
nice work on asmparser. I think that once libsystem/support/bytecode are converted over, we would be ready to make the big switch. Stuff like libdebugger/bugpoint are a big deal.
Reminder: This patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060814/036868.html which comments out setting -fno-exceptions, needs to be reverted once the Bytecode, Support and System libraries are exception free.
With numerous recent patches (too many to list here), we are now exception free in the lib/System, lib/Support, and lib/VMCore libraries. The only remaining exception code is in lib/Bytecode and lib/Debugger. .. getting closer.
A note: the only tool that uses libdebugger is llvm-db. Once the .bc handling stuff is EH free, almost all of LLVM (everything but libdebugger and llvm-db) could have -fno-exceptions enabled. -Chris
Yes, that's what I was planning to do .. leave REQUIRES_EH turned on in lib/Debugger and tools/llvm-ld and then uncomment the -fno-exceptions lines in Makefile.rules so that the rest of LLVM is exception free. Unfortunately, getting the exceptions out of the Archive/Bytecode stuff is non-trivial, but it will happen soon. Mine.
Fixed. LLVM now builds with -fno-exceptions except in lib/Debug and the tools. This leads to the following reduction in library and executable sizes for an X86/Linux platform: DEBUG BUILD RELEASE BUILD before after delta before after delta lib 162,328K 157,616K 4,712 17,864K 16,416K 1,448K bin 571,444K 557,156K 14,288 63,296K 56,996K 6,300K Debug Improvement: 19,000K (2.59%) Release Improvement: 7,748K (9.55%)