[PATCH] D70079: [SelectionDAG] Combine U{ADD,SUB}O diamonds into {ADD,SUB}CARRY

[David Zarzycki via Phabricator via llvm-commits]

davezarzycki added a comment.

In D70079#1745594 <https://reviews.llvm.org/D70079#1745594>, @spatel wrote:

> In D70079#1745241 <https://reviews.llvm.org/D70079#1745241>, @davezarzycki wrote:
>
> > 1. Why is UADDO/USUBO an intrinsic but ADDCARRY/SUBCARRY is not? This is unfortunate given that clang and perhaps other languages have addcarry/subcarry intrinsics.
>
>
> I don't know the full history, but my guess is that the *.with.overflow intrinsics were assumed to be good enough to hold the patterns together through IR optimization, and the backend could relatively easily map those to DAG nodes. If that's not correct, then we could make a case for adding to, extending, or replacing the current set of intrinsics.
>
> That does lead to questions I was already wondering about:
>
> 1. Can we do this transform in IR (instcombine)?
> 2. There are tests with intrinsics and tests with "raw" IR - are we missing IR transforms that should canonicalize to 1 form or the other?


As the first question and according to the SCM history (r234638 / b6c5914308132acc9289335ed6a92b31f9484631):

> This change moves creating calls to `llvm.uadd.with.overflow` from InstCombine to CodeGenPrep.  Combining overflow check patterns into calls to the said intrinsic in InstCombine inhibits optimization because it introduces an intrinsic call that not all other transforms and analyses understand.

As to the second question, the tests with intrinsics was generated via clang's __builtin_addc/subc. The tests without intrinsics were generated via pure C and hence more potential solutions exist that can be matched.

[EDIT] – I should add that CodeGenPrep doesn't match all eligible cases where `llvm.uadd.with.overflow` is possible, which hurts this proposed optimization.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70079