[llvm-dev] Poison/Undef at CodeGen level Was: [poison] is select-of-select to logic+select allowed?

[Matthias Braun via llvm-dev]

> Regarding SDAG, and given that poison is already there, we would need to adopt a similar solution to the IR.  Maybe right now we can get away with it because nsw is not exploited significantly (as you say).  Just because there’s no explicit poison in SDAG, just having nsw is sufficient to cause miscompilations when combined with other transformations.
> See, for example, this bug report for InstCombine regarding select+nsw: https://bugs.llvm.org/show_bug.cgi?id=31633 <https://bugs.llvm.org/show_bug.cgi?id=31633>
Poison/Undef at the CodeGen level is a very interesting discussion! I don't think there is any documentation about posion/undef at the CodeGen level and I haven't discussed this much with others, so I'd like to hear further feedback:

- I think we should not introduce a notion of poison (which I would call "delayed UB") at the SelectionDAG/CodeGen level[1]
- Instructions either produce UB immediately, so while there are nsw/nuw flags on SelectionDAG arithmetic operatiosn I think we can only assume that they produce a target specific value on overflow, but not arbitrary behavior. Instructions that can produce UB should marked "hasSideEffect" and code motion around it be limited.
- Typical optimization scenarios like establishing loop trip count bounds for which poison/UB is helpful should not matter for CodeGen.
- I don't have any evidence that optimizations in CodeGen require a model of poison to work. If someone can given me a counter example then I'd be hard pressed to disable the optimization in MI and push it towards the IR level.

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170526/13c90dff/attachment.html>