[PATCH] Add new LLVM_OPTIMIZED_TABLEGEN build setting which configures, builds and uses a release tablegen build when LLVM is configured with assertions enabled.

[Reid Kleckner]

On Mon, Feb 9, 2015 at 2:52 PM, Chris Bieneman <beanz at apple.com> wrote:

> For one, setting -DNDEBUG on parts (but not all) of the code isn’t safe.
> We have headers in libSupport that change ifdef on NDEBUG, and that could
> cause subtle bugs.
>

$ git grep NDEBUG ../include/llvm/Support/
../include/llvm/Support/Allocator.h:#ifndef NDEBUG
../include/llvm/Support/Allocator.h:#ifndef NDEBUG

I added these long ago, let's remove them.

../include/llvm/Support/Compiler.h:#if !defined(NDEBUG) ||
defined(LLVM_ENABLE_DUMP)

We could work around this by defining LLVM_ENABLE_DUMP as well as NDEBUG.

../include/llvm/Support/Debug.h:#ifndef NDEBUG

Ouch, that is used, but I suppose we want this to be compiled out of
Support and TableGen LLVM_OPTIMIZED_TABLEGEN is on.

../include/llvm/Support/ErrorHandling.h:/// In !NDEBUG builds, prints the
message and location info to stderr.
../include/llvm/Support/ErrorHandling.h:/// In NDEBUG builds, becomes an
optimizer hint that the current location
../include/llvm/Support/ErrorHandling.h:#ifndef NDEBUG

Implementation of llvm_unreachable, we want this.

../include/llvm/Support/Valgrind.h:#if LLVM_ENABLE_THREADS != 0 &&
!defined(NDEBUG)
../include/llvm/Support/Valgrind.h:#if LLVM_ENABLE_THREADS != 0 &&
!defined(NDEBUG)

Valgrind is dead, long live the sanitizers.


> Also I don’t like the idea of bleeding the non-debug code into what you
> might be debugging. It would kinda suck to be debugging something and
> suddenly lose your debug granularity because you stepped into optimized
> code.


Yeah, but Support is pretty well tested. I think this is a reasonable cost
for LLVM_OPTIMIZE_TABLEGEN.


> One of the big appeals to me about using the cross-compiling support for
> this is it means that your output from a debug build remains the same
> (barring debug tablegen behaving wildly different from a release one).


That's a reasonable concern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150209/eb642368/attachment.html>