Compile VMCore with -fno-exceptions

[llvmbot]

Bugzilla Link	797
Resolution	FIXED
Resolved on	Feb 22, 2010 12:47
Version	1.0
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

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.

[lattner]

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

[llvmbot]

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.

[lattner]

Sounds good.

I don't remember the specifics, but coverity uncovered a number of them, which I fixed back then.

[llvmbot]

What's the status of this? Are we trying to remove exceptions from all of LLVM
for 1.8?

[lattner]

Not going to happen for 1.8. Hopefully for 1.9, we're pretty close already.

-Chris

[llvmbot]

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.

[lattner]

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

[llvmbot]

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.

[llvmbot]

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

[lattner]

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.

[llvmbot]

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.

[llvmbot]

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.

[lattner]

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

[llvmbot]

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.

[llvmbot]

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%)