[llvm] r310075 - Port libFuzzer tests to LIT. Do not require two-stage build for check-fuzzer.

[George Karpenkov via llvm-commits]

> 
> Yes, that's awkward on its own, but sometimes you're doing that
> *anyway*. In particular, when I'm building an LLVM fuzzer tool (like the
> forthcoming llvm-isel-fuzzer) on a branch of LLVM I'm obviously building
> with coverage. I'd like to be able to run the fuzzer tests to verify
> that the libFuzzer I'm linking that against works.
> 
>> After offline conversation:
>> - seems that libFuzzer is correctly built without coverage, and
>>   slowdown was probably caused by something else.
>> - the aforementioned problems should disappear once libFuzzer is
>>   moved to compiler-rt and becomes a part of clang's toolchain.
> 
> Yes, once libFuzzer is distributed with the compiler these issues go
> away - at that point the libFuzzer and the clang that you're using are
> tested together.
> 
> If that's happening in the next couple of weeks I'm comfortable with
> waiting for it, but if it's likely to be months I think we need a way to
> say "test with the host compiler". A CMake variable would work, but I
> actually think doing that by default if LLVM_USE_SANITIZE_COVERAGE is
> true would be even better.

I think https://reviews.llvm.org/D36883 should solve your problems.

Additionally, I think relying on LLVM_USE_SANITIZE_COVERAGE is not a good idea:
libFuzzer is a tool in itself, and using it to fuzz LLVM is just one of possible applications,
which definitely should not change how the library is compiled (e.g. it would be better to simply
always append a flag which specifies that libFuzzer is compiled with no coverage,
regardless of what LLVM_USE_SANITIZE_COVERAGE is set to).