[PATCH] D34300: [AMDGPU] simplify add x, *ext (setcc) => addc|subb x, 0, setcc

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In https://reviews.llvm.org/D34300#784772, @rampitec wrote:

> In https://reviews.llvm.org/D34300#784771, @arsenm wrote:
>
> > In https://reviews.llvm.org/D34300#782902, @rampitec wrote:
> >
> > > In https://reviews.llvm.org/D34300#782899, @arsenm wrote:
> > >
> > > > Why does this need to be a target combine? Can't we use the sub with overflow generic nodes?
> > >
> > >
> > > Surprisingly ISD::ADDE and ISD::SUBE expect two operands, regardless of what is written in documentation. See for example this pattern with two inputs:
> > >
> > >   let Uses = [SCC] in { // Carry in comes from SCC
> > >   let isCommutable = 1 in {
> > >   def S_ADDC_U32 : SOP2_32 <"s_addc_u32",
> > >     [(set i32:$sdst, (adde (i32 SSrc_b32:$src0), (i32 SSrc_b32:$src1)))]>;
> > >   } // End isCommutable = 1
> > >
> > >
> > > So I did it the same way as ARM.
> >
> >
> > I meant the other sets of add/sub nodes, like ISD::SADDO. The input is a n allocatable register bool like how the instructions work rather than a flag relying on glue like ADDE
>
>
> It produces flag, not consumes it. Also it distinguish between signed/unsigned.


I think the right one is    ADDCARRY, SUBCARRY:

The use of this opcode is preferable to adde/sube if the

  /// target supports it, as the carry is a regular value rather than a
  /// glue, which allows further optimisation.


Repository:
  rL LLVM

https://reviews.llvm.org/D34300