search for: uaddo

On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: > For targets where ADDCARRY and SUBCARRY are legal, would it make sense > to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? SelectionDAG will never generate ADDC/ADDE on targets where they aren't legal.  Targets which custom-lower ADDCARRY generally also custom-lower UADDO; not sure what sort of expansion you're thinking of. -Eli -- Employee of Qualcomm Innovatio...

On 5/30/2018 1:16 PM, Friedman, Eli wrote: > On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: >> For targets where ADDCARRY and SUBCARRY are legal, would it make sense >> to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? > > SelectionDAG will never generate ADDC/ADDE on targets where they aren't > legal.  Targets which custom-lower ADDCARRY generally also custom-lower > UADDO; not sure what sort of expansion you're thinking of. If ADDC/ADDE cannot...

On 5/30/2018 11:28 AM, Krzysztof Parzyszek wrote: > On 5/30/2018 1:16 PM, Friedman, Eli wrote: >> On 5/30/2018 10:29 AM, Krzysztof Parzyszek via llvm-dev wrote: >>> For targets where ADDCARRY and SUBCARRY are legal, would it make >>> sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? >> >> SelectionDAG will never generate ADDC/ADDE on targets where they >> aren't legal.  Targets which custom-lower ADDCARRY generally also >> custom-lower UADDO; not sure what sort of expansion you're thinking of. > &...

These opcodes have been deprecated about a year ago, but still in use in various backend. In https://reviews.llvm.org/D47422 I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default. This

For targets where ADDCARRY and SUBCARRY are legal, would it make sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? Are there plans to deprecate UADDO/USUBO in favor of ADDCARRY/SUBCARRY? -Krzysztof On 5/30/2018 11:57 AM, Amaury Séchet via llvm-dev wrote: > These opcodes have been deprecated about a year ago, but still in use in > various backend. > >...

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming that the only thing which can be used as...

...| 8 ++ > lib/Target/R600/EvergreenInstructions.td | 3 + > lib/Target/R600/R600ISelLowering.cpp | 39 +++++++- > test/CodeGen/R600/add.ll | 154 +++++++++++++++++-------------- > test/CodeGen/R600/sub.ll | 18 ++-- > test/CodeGen/R600/uaddo.ll | 17 +++- > test/CodeGen/R600/usubo.ll | 23 ++++- > 9 files changed, 189 insertions(+), 81 deletions(-) > > diff --git a/lib/Target/R600/AMDGPUISelLowering.h b/lib/Target/R600/AMDGPUISelLowering.h > index 911576b..6eaf001 100644 > --- a/lib/Targ...

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

...transform, with the way the ADDC/ADDE opcodes are currently defined, and to do it you really need to fix the opcode definitions to not involve glue, first. I also note that your transform doesn't actually trigger at all on this particular test case on x86, because the dag ends up looking like (uaddo X, (adde Y, 0, Carry)), which the transform doesn't match. That is not really relevant to the issue here, because the x86 backend does work even if the transform gets triggered (replacing the final store with "store i64 %add37, i64* %r, align 8" will make this happen) On Tue, Feb 7,...

...t;mul->lshr->trunc llvm.fixsmul.sat.iN(iN A, iN B, i32 Scale) = sext->mul->ashr->ssat->trunc llvm.fixumul.sat.iN(iN A, iN B, i32 Scale) = zext->mul->lshr->usat->trunc llvm.sadd.sat.iN(iN A, iN B) = saddo->check sign&ovf->selects llvm.uadd.sat.iN(iN A, iN B) = uaddo->check ??&ovf->selects etc. The operations that the intrinsics are expressed in are strictly different anyway (sext vs zext, saddo vs uaddo etc), so there isn't any room for generalization on constant parameter values in the first place. You'll need to disambiguate manually re...

Would it not make sense to refactor the code so those don't use glue rather than emitting them with glue and then getting rid of it. There are times when we would like to emit these in separate blocks but can't (presumably because of the glue). On Tue, Feb 7, 2017 at 9:15 PM, James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That's seems really odd that

On 2018-08-22 05:56, John McCall via llvm-dev wrote: >> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >> If we were to create a new type down the line, I think the main >> features that would distinguish them from other types are the >> arbitrary width and scale. Saturation can be handled through >> instructions since saturation

Hi All, The following code : void hexagon2( int *a, int *res ) { int i = 100; while ( i-- ) { *res++ = *a++; } } gets compiled as a sub-optimal Software loop on LLVM 9.0 instead of a Hardware loop, whereas it was compiled as a Hardware Loop in LLVM 7.0. This is the final assembly code generated by LLVM 9.0 : .text .file "main.c" .globl hexagon2 // --

...the bigger problems with using tablegen's DAG type is that it doesn't deal with multi-result instructions very well. Every time this has been raised on the list w.r.t SelectionDAG the solution has boiled down to 'use C++ instead' and it would be good to fix that so that things like UADDO are representable. You can write a rule that matches something like divmod at the top-level using the 'set' operator: (set $D1, $D2, (divmod $A, $B)) but as soon as it's not the top-level, it gets really ugly fast even using pseudo-nodes: (set (outs $D1, $D2), (sext (result (G_DIVMO...

...the bigger problems with using tablegen's DAG type is that it doesn't deal with multi-result instructions very well. Every time this has been raised on the list w.r.t SelectionDAG the solution has boiled down to 'use C++ instead' and it would be good to fix that so that things like UADDO are representable. You can write a rule that matches something like divmod at the top-level using the 'set' operator: >> (set $D1, $D2, (divmod $A, $B)) >> but as soon as it's not the top-level, it gets really ugly fast even using pseudo-nodes: >> (set (outs $D1, $...

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.