[llvm] [IsolatePath] Add a pass to isolate paths with undefined behavior (PR #146791)

[Bill Wendling via llvm-commits]

bwendling wrote:

> > > I fundamentally disagree with what this is trying to do. _I_ want paths that always lead to UB to be eliminated. Both as a user of C/C++, but especially as a user of memory safe languages.
> > 
> > 
> > This pass does exactly this. It isolates the paths with explicit undefined behavior (`nullptr` accesses) so that they can be eliminated. I suppose the only controversial element here would be a retained `load` and use of `__builtin_trap()` on the UB path. How this differs from what we currently have is that it applies a finer-toothed comb to the code. It isolates the bad paths so that the good paths aren't affected.
> 
> Retaining the load and trap is exactly the problem. This means that the UB-triggering path is explicitly retained, not optimized away. Most importantly, the control flow deciding whether to take that path is not optimized away.
> 
> This is also why I called this a hardening pass: It replaces UB with traps.

Okay. Then I can put those parts behind a flag. They're a "nicety" to preserve some semantics, but probably aren't 100% necessary. :-)

> > What guidance?
> 
> That function fallthrough due to UB can be prevented using trap-unreachable mode, and I'd be open to having it enabled by default. This is in reference to this code comment: "This prevents code generation where, after the UB instruction's eliminated, the code can wander off the end of a function."

I agree that a trap-unreachable is far better than the alternative.

> Maybe I misunderstood everything here, and your actual intention is to strengthen the optimization performed by removeUndefIntroducingPredecessor() using a dedicated pass -- but in that case this code should be eliminating UB paths, not converting them to traps, and function fallthrough should be addressed via trap-unreachable.

It's easy to remove them. I'll submit a change.

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