[PATCH] Added InstCombine transform for pattern " ((X % Z) + (Y % Z)) % Z -> (X + Y) % Z ".

[Nuno Lopes]

>>! In D5351#17, @ankur29.garg wrote:
> Thanks for clarifying that. I understand now, what that undefined behavior is for.
> 
> Another thing, in these examples, all three inputs, %x, %y, & %z are known. That is, they are constants. I think such cases wouldn't make it to the transformation. When I was testing the transformation, I tested it with these inputs, the part of the code where the transformation takes place was never reached.
> The transformation is useful only when some (or all) bits of any of these inputs are unknown. Otherwise, direct calculation of the expression is done. So, there should be no change in the behavior for the above input, as, in case of this input, this transformation will never be applied.
> 
> Thanks.

So the counterexample shows concrete, constant, values, yes.  But that doesn't mean that you need to have these constants in the IR.
This counterexample means that if you do this transformation, and if at run time, it happens that %x,%y,%z have the values that I've given you previously, then the program would execute undefined behavior.  For example, if a subsequent optimization pass folds all %x,%y,%z to the constants I gave you, it will detect the undefined behavior and it can then remove all the code.
So, the optimization you're proposing introduces undefined behavior for one particular input (of %x,%y,%z) where the original code had defined behavior.  Therefore the transformation is not safe.

http://reviews.llvm.org/D5351