[PATCH] D74228: [PatternMatch] Match XOR variant of unsigned-add overflow check.

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Feb 16 06:15:56 PST 2020


spatel added a comment.

In D74228#1877776 <https://reviews.llvm.org/D74228#1877776>, @nikic wrote:

> Taking a step back here, I'd like to question why InstCombine does this fold in the first place. This was introduced in https://github.com/llvm/llvm-project/commit/1cf0734b2f6b346993c41c18f4d6a9f2d1e11189, but I'm not quite clear on the motivations (and if they still apply after we introduced saturation intrinsics?). As we consider `a + b < a` the canonical overflow pattern for the case where `a + b` is used, why wouldn't we use the same pattern for the case where it is not used as well?


The transform makes sense in IR because it eliminates a use of a variable and trades an 'add' for a 'not' - both of those are better for analysis and enabling subsequent folding. If we are questioning that transform, then we have to be ok with reversing that transform: turn 'not' into 'add' and create an extra use of a variable. To do that, we'd need to show that that is at least not harmful in codegen. Given the history of regressions using overflow intrinsics, I'm skeptical that we want to reverse that. For similar reasons, I don't think we want to canonicalize to overflow intrinsics if we're not using the math part of the op - that would be harmful to IR-level transforms and codegen unless we teach every pass to undo those?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74228/new/

https://reviews.llvm.org/D74228





More information about the llvm-commits mailing list