Llvm_unreachable is widely misused

[fhahn]

AFAIK there are multiple active projects that are continuously fuzzing LLVM/Clang.

Some examples:

• oss-fuzz (using libfuzzer I think, see llvm/tools/llvm-*-fuzzer), list of found issues Monorail - oss-fuzz - OSS-Fuzz: Fuzzing the planet - Monorail
• EMI & SPE Compiler Testing, list of found issues https://github.com/llvm/llvm-project/issues?q=is%3Aissue+author%3Azhendongsu+

Any additional efforts could be very valuable. Especially the LLVM IR fuzzers are quite limited in the type of candidates they currently produce AFAIK.

[bjacob]

FYI this is how one dependent project (IREE) resolved this conversation. Replace llvm_unreachable by assert(false) or pass failures by bjacob · Pull Request #8521 · iree-org/iree · GitHub

[mehdi_amini]

It’d be interesting to systematically replace

@jdoerfert

If we up our game on llvm.trap handling we can probably get similarly fast code with __builtin_trap as we have with __builtin_unreachable today. That would mean we have a) in debug mode mode and b) in release mode. While performance impact has to be actually verified (esp. with other compilers), I find b) in release mode w/o assertions a reasonable compromise.

I think that’s a great idea to experiment with!
It is also a trivial CMake flag to get this behavior available I think: ⚙ D121750 Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled

[mehdi_amini]

This landed FYI: Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() whe… · llvm/llvm-project@6316129 · GitHub

[DataCorrupted]

Especially the LLVM IR fuzzers are quite limited in the type of candidates they currently produce AFAIK.

I scanned through LLVM’s code, seems we have already had a IR fuzzing framework (llvm/lib/FuzzMutate).

Is that everything we have? I do plan on doing some work on IR fuzzing.