Disabling rtti on default build - could it be reverted/re-enabled?

We at Tampere University of technology are using LLVM for high-level optimizations in the compiler for our TTA processor toolkit(TCE)

We have a llvm backend which creates our own intermediate code, and our own instruction selector after that (as LLVM's machine code cannot represent the actual machine codes of our processors).

This makes our llvm backend quite different from the ordinary llvm backends, and we have to link lots of code to same binaries which also link to llvm libraries.

LLVM 2.7 is dropping rtti on default build, which is a problem to us.
We are using Boost libraries on many places in our code, and Boost has some heavy usage of type info tricks, which cannot be compiled without rtti, so we have to keep rtti on for our code.

But our code also implements the llvm backend framework classes, which are compiled without rtti , which causes problems; we cannot derive from the non-rtti enabled base classes with derived classes that are compiled with rtti on.

So could rtti be turned on for default builds of llvm so that we could continue using (non-customized) llvm libraries for our compiler?

Just having rtti on should not cause you any performance deficits, just causes some extra typeinfo methods to be created to your binaries, and these should be quite small so they should not make them much larger.

Hi Heikki,

You should be able to get this by doing "make REQUIRES_RTTI=1" when building LLVM.

-Chris

What is the main reason RTTI is now disabled by default? We discussed
this briefly in IRC but could not reach a proper conclusion and I was
directed to ask here for the proper reason against it.

Having RTTI support in should not have execution speed penalties, only
using the typeinfo does, and binary size benefit is also very small.

Seems this has been discussed a while ago, but I'd like to ask to
reconsider:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028970.html

It would be better to have the support on by default as having it on should
not break the majority of clients (RTTI on is the default for g++ at least) to
the LLVM lib. It now breaks for us, and I have a feeling we are not the only
ones. Especially now that the shared lib generation has been fixed, I predict
use cases like ours won't be all that uncommon (clients to libLLVM*.so that
use also libs like Boost that require RTTI).

Mainly this is about a nuisance to need to ask users of TCE to recompile
LLVM (which might be even installed from a precompiled binary for their distro) to be able to compile TCE.

It's not easy to get rid of RTTI requiring code for us as we use Boost
heavily in our derived MachineFunctionPasses.

You should be able to get this by doing "make REQUIRES_RTTI=1" when building LLVM.

What is the main reason RTTI is now disabled by default? We discussed
this briefly in IRC but could not reach a proper conclusion and I was
directed to ask here for the proper reason against it.

Code size (e.g. on disk) and compile time.

Having RTTI support in should not have execution speed penalties, only
using the typeinfo does, and binary size benefit is also very small.

It was ~5% last time I measured it, which is actually quite a big deal.

It would be better to have the support on by default as having it on should
not break the majority of clients (RTTI on is the default for g++ at least) to
the LLVM lib. It now breaks for us, and I have a feeling we are not the only
ones. Especially now that the shared lib generation has been fixed, I predict
use cases like ours won't be all that uncommon (clients to libLLVM*.so that
use also libs like Boost that require RTTI).

The LLVM build system makes it really easy to turn RTTI on if you want it, so I don't see why this is any different than -fexceptions, -fvisibility-inlines-hidden, or one of many other code gen changing flags that you could build LLVM with.

Mainly this is about a nuisance to need to ask users of TCE to recompile
LLVM (which might be even installed from a precompiled binary for their distro) to be able to compile TCE.

I'm dubious that doing that would actually work anyway. Since LLVM doesn't provide a stable API, being able to reuse a previously installed version of llvm is not very likely to work.

-Chris

Chris Lattner wrote:

Mainly this is about a nuisance to need to ask users of TCE to recompile LLVM (which might be even installed from a precompiled binary for their
distro) to be able to compile TCE.

I'm dubious that doing that would actually work anyway. Since LLVM doesn't
provide a stable API, being able to reuse a previously installed version of
llvm is not very likely to work.

Yes, we as an external project using LLVM as a library are painfully
familiar with the unstable API by now :slight_smile:

Anyhow, people might have LLVM (a supported version) installed (compiled
with the default compilation flags or installed from a binary package
of their distro) for other reasons than compiling TCE.

From now on these users need to recompile LLVM from sources with non-default
flags to make TCE (or other external projects using both LLVM and RTTI) to
be able to link with it. I think this should matter something in comparison to
a 5% disk size reduction which can be still achieved with disabling RTTI
when compiling LLVM for low disk space devices or during LLVM development
that requires frequent recompiles.

As far as I understood, enabling RTTI by default does not break any
clients, but disabling does. So I guess it's a matter how much value
the LLVM project gives to external projects using LLVM as a library.

How much is the compile time speedup BTW, has it been measured?

Pekka Jääskeläinen wrote:

Mainly this is about a nuisance to need to ask users of TCE to recompile
LLVM (which might be even installed from a precompiled binary for their
distro) to be able to compile TCE.

I highly recommend that any packagers turn on RTTI for their shipping builds of LLVM, in order to increase the chance of the library being reusable.

Nick

From now on these users need to recompile LLVM from sources with non-default

flags to make TCE (or other external projects using both LLVM and RTTI) to
be able to link with it. I think this should matter something in comparison to
a 5% disk size reduction which can be still achieved with disabling RTTI
when compiling LLVM for low disk space devices or during LLVM development
that requires frequent recompiles.
   
I think Chris means 5% runtime speed, which matters

regards,

IMO, if you wish to preserve the ability to ever turn off RTTI, you
must turn it off by default for the developers' builds so that any
code which might depend on RTTI breaks immediately. Otherwise, it
seems only a matter of time before dependencies slowly creep back into
the code base. This has certainly proven true with GCC warnings. =/ I
think Nick has it right: developers should build with the most
restrictive settings expected to work, packagers should build with the
most forgiving settings they can tolerate.

Yes, I see the point and benefits in having RTTI disabled by default
during LLVM development.

Releases are a different story. That is, what should the distributed
tar balls configure with by default. IMHO end users should get RTTI
enabled by default as it is less likely to break stuff for them later.

I mean, one doesn't usually think things like this when one
installs a piece of software from sources: "Maybe I should disable
this default flag because maybe a software I'm going to try
in 3 weeks breaks unless I do it".

As far as I know, RTTI enabled should not increase execution time in
case RTTI features (typeinfo, dynamic_cast) are not used. Please
correct me if I'm wrong.

I agree, release code should be optimized for reliability even if that
has a small efficiency cost. IIRC, RTTI just uses the vtable pointer
that exists anyway, I wouldn't have thought it would have a speed
penalty?

Seems Ubuntu 10.04 LTS is going to ship LLVM 2.7. I sent a request
for enabling RTTI on the package, I hope it's not too late for that:

https://bugs.launchpad.net/ubuntu/+source/llvm/+bug/526072

I've put together http://llvm.org/docs/Packaging.html to document
these kinds of requests for all packagers in one place. Let me know if
any of the advice I've put there is wrong. (At the moment,
http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Packaging.html?view=co
is more up to date, but the website should catch up sooner or later.)

Jeffrey Yasskin wrote:

I've put together http://llvm.org/docs/Packaging.html to document
these kinds of requests for all packagers in one place. Let me know if
any of the advice I've put there is wrong. (At the moment,

Looks good to me. BTW exception support for LLVM is not required
to link with code that uses exceptions. At least our toolset
seems to link fine with LLVM without this flag given for make and
it uses exceptions all over the place. So probably it's not required
to be on for the binary packages either (not sure about this).

About --enable-shared. Could it be a good compromise to allow to
link the LLVM tools statically (for the startup speedup) but still
generate also a shared lib for external projects to more easily link
with? So, by default always (additionally to the static lib) generate
the big .so but only when --link-llvm-with-shared (or similar)
is given it would link the LLVM binaries with it?

Pekka Jääskeläinen wrote:

Jeffrey Yasskin wrote:

I've put together http://llvm.org/docs/Packaging.html to document
these kinds of requests for all packagers in one place. Let me know if
any of the advice I've put there is wrong. (At the moment,

Looks good to me. BTW exception support for LLVM is not required
to link with code that uses exceptions. At least our toolset
seems to link fine with LLVM without this flag given for make and
it uses exceptions all over the place. So probably it's not required
to be on for the binary packages either (not sure about this).

The reason we can't turn RTTI off for VMCore right now is that it breaks the build on Mac of tools/bugpoint which uses RTTI (because it uses exceptions). Your ABI may vary.

Nick

That's RTTI, not exceptions. If both had RTTI on, but bugpoint used
exceptions and VMCore didn't, Pekka's saying it would still link
(which seems, actually, to be the current state of the world). I'll
remove the REQUIRES_EH item.

It would be straightforward to add another option controlling how the
tools are linked (I'm not planning to do it, but you can), but
building the shared library by default broke things on ARM, darwin-8,
and apple's internal builds. That's why it's off by default.