llvm dev - Feb 2010 - [LLVMdev] Disabling rtti on default build - could it be reverted/re-enabled?

On 02/17/2010 09:58 PM, Chris Lattner wrote:
> 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.

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.

-- 
Pekka

On Feb 18, 2010, at 1:54 AM, Pekka Jääskeläinen wrote:
> On 02/17/2010 09:58 PM, Chris Lattner wrote:
>> 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 :)

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

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

On 02/19/2010 07:55 AM, Nick Lewycky wrote:
> 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.
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

-- 
Pekka