[llvm-dev] A thought on poison and select semantics

[Philip Reames via llvm-dev]

When working on a couple of recent changes in SCEV, I stumbled on a 
couple of gaps around how we optimize the @llvm.umin intrinsics.  If I 
remember correctly, we added these because they needed different poison 
propagation semantics than select, and that memory triggered a thought.

I want to raise the question of whether we should support both possible 
poison propagation semantics for the select instruction. As a brief 
review, the two options are:

 1. Poison propagates only through the selected operand.  e.g. "select
    i1 true, i32 0, i32 poison" is not poison.
 2. Poison propagates if any operand is poison.  e.g. "select i1 true,
    i32 0, i32 poison" is poison.

Each of the two options has advantages.  This was discussed in depth a 
while ago, and we'd picked (1).  I don't want to reopen that discussion; 
I want to raise the question of whether we should pick "both".

If we were to add a flag "npo" (for "no poison operand", bikeshedding 
welcome!) to the select instruction, we could represent both options.  
This has a couple of advantages:

  * We can lower all of the umin/etc.. intrinsics to selects and avoid
    having to duplicate folds.  This  would reduce the combinatoric
    space for pattern matching optimizations.  This would probably help
    optimization results in practice.
  * We can restore many of the removed select->arithmetic folds (only
    for the npo selects).
  * We can infer npo flag on a select in many cases.  (e.g. "select i1
    %c, i32 0, i32 57" can be trivially converted to "select npo i1 %c,
    i32 0, i32 57")  This also allows us to factor logic into testable
    pieces whereas current transforms which are npo dependent must
    include the no-poison inference.

The major downside is that transformation code would have to be careful 
to only apply transforms dependent on "no poison operand" if the flag is 
set.

Anyways, I don't have time to actually work on this, so I'm mostly 
throwing out the idea in case anyone with time and motivation finds it 
interesting to pursue.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210701/4495897b/attachment.html>