[PATCH] LLVM 2.8 fixes

[Daniel Dunbar]

On Thu, Aug 5, 2010 at 10:54 AM, Peter Collingbourne <pcc03 at doc.ic.ac.uk> wrote:
> On Thu, Aug 05, 2010 at 05:44:42PM +0100, Daniel Dunbar wrote:
>> > I'll commit this unless there is an objection.
>>
>> Sure, please do.
>
> Applied in r110349-52.
>
>> I'm ambivalent about the 0001- change, though, although it is fine to
>> put it in. It isn't really a complete solution -- technically we would
>> need to have the test be based on the LLVM version, and then set or
>> unset DISABLE_ASSERTIONS as appropriate. Of course, then that is very
>> confusing because users then need to be aware of the change when
>> configuring KLEE.
>>
>> Now that we have some support for optimized debug info in KLEE, I'm
>> beginning to think we should just eliminate the configure option for
>> which mode to build the runtime library in. It is too complicated and
>> annoying to deal with. Do you have an opinion on this?
>
> If we do anything at all, the runtime library mode should by default
> match the mode that LLVM was built with.  I have been caught by this
> a couple of times when building LLVM in Debug mode; the build process
> for the runtime library tries to use Release binaries and fails unless
> I use --with-runtime=Debug.

Yeah, I agree.

> Perhaps we should have the mode always match but include the capability
> to control assertions and optimisations independently.  That way we
> don't need to care about the semantics of the various build modes
> in different versions of LLVM.  I have not yet needed to modify the
> runtime library to the extent that I have needed to control whether
> assertions or optimisations are turned on, but this could be useful
> for others.  I haven't looked at the code to see how feasible this
> would be.

I like this idea. I can probably make this work, and have the runtime
library default to whatever makes the most sense for users. In
practice, most people never will need an unoptimized runtime library.

> I also wonder if it would be worthwhile to turn on optimisations
> by default for the runtime library regardless of the build mode.
> This would ensure consistency between build modes -- for example, I
> recently tweaked one of the LLVM optimisations to add a feature that
> may reduce the number of forks KLEE needs to make, and I imagine that
> other optimisations could have a similar effect.  I haven't checked
> to see if they would have an effect on the runtime library though.

The historical problem here was that turning on optimizations would
kill debug info -- usually the only reason to use a debug runtime
library was to get debug info (for example, to view things in
kcachegrind).

 - Daniel

> Thanks,
> --
> Peter
>