[llvm] [llubi] Experimental support for noalias (PR #195808)

[Bruno De Fraine via llvm-commits]

brunodf-gf wrote:

It would be very nice to see noalias support in llubi!

I tested this PR, and it does give the noalias semantics that I expect in the examples that I tested, but the protectors and state machines do seem rather complex/inefficient: when there are multiple noalias parameters A, B,... for the same function they will do "symmetrical" transitions and often multiple state machines will reach UB simultaneously. It seems this could be simplified/optimized by tracking (per function activation) whether there was memory access:
- using noalias parameter A,
- using noalias parameter B,
- using noalias parameter ...,
- not using any noalias parameter of this function,
- or using multiple of the above

Then you have UB iff there was memory access using "multiple of the above" and the memory is written (during the function activation). It seems this would yield UB (or no UB) in exactly the same circumstances as what you have here, but it would track this more directly (less state and transitions). [Note: this optimization is not a new idea, it is essentially the "restricted target set" formulation from Homer and MacDonald in [N3058](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3058.htm) but from the point-of-view of the memory objects rather than from the restrict pointers.]

Another question is about the synthetic actions at the protector end, the part that begins here:
https://github.com/llvm/llvm-project/blob/834527593b85f7121c6fde57d7d86502335846ae/llvm/tools/llubi/lib/Context.cpp#L1006
I could never see any effect of these (they always seem to transition to the state they are already in). Do you have an example where these actions make a difference (between UB and no UB)? The blog post that you reference just says they are "necessary for complicated reasons" but we'll need to understand this better than that.

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