[llvm] [RFC][BPF] Report Unreachable Behavior from IR (PR #126858)

[via llvm-commits]

yonghong-song wrote:

> I was curious if there are other cases besides switch instruction, where `unreachable` could survive up to codegen. Unfortunately, `unreachable` is generated in a lot of places with complex logic, e.g. loop fusion or SCCP. It looks like it is impossible to know the answer for sure.

Could you share the details about these experiments? I would like to see whether I missed anything which we should cover?

> 
> Given this, I tend to agree that a runtime trap would be a simpler solution. E.g. something along the lines libbpf does [here](https://github.com/libbpf/libbpf/blob/42a6ef63161a8dc4288172b27f3870e50b3606f7/src/libbpf.c#L6062), where it inserts a call to unknown helper function. In kernel `verifier.c:get_helper_proto()` is only called from `check_helper_call()` on main verification pass. Meaning that if `unreachable` is a dead code, verifier would delete it, otherwise it would report an error.

Regarding to runtime trap, I actually examined this as well before going to compiler approach.  That approach is to change 'unreachable' to some newly created trap insn and later on when verifier reaches these trap insn, verification will fail. But I did a few examples and found that only limited patterns so I prefer to use the compiler approach. Note that the 'unreachable' checking is done at roughly the end of middle end optimizaiton (i.e. beginning of backend IR passes).

So let us gather more examples here before considering going to bpf verifier to deal with these 'unreachable' traps. Note that there is risk that these 'unreachable' traps may be rejected by verifier but actually it may be safe because of verifier some in-precise analysis. So the best way is to do at runtime, but it has its own complication. 

> 
> Verifier can be changed to report something about undefined behaviour trap to simplify debugging. BPF backend can be changed to avoid clobbering registers because of this special trap call.

So my suggestion is to let us do some thorough analysis at compile time. Note that it is always better for compiler to flag something first. If eventually it turns out there are too many patterns which may have *fake* unreachables, then we could consider run-time approach then.

> 
> Just my 5 cents.



https://github.com/llvm/llvm-project/pull/126858