search for: addcarry

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 expa...

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; no...

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 >> cus...

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...

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

Dear all, a couple of new generic DAG nodes ISD::ADCARRY and ISD::SUBCARRY were recently introduced in https://reviews.llvm.org/D29872 These nodes have three inputs and two outputs, the second output being the "carry". I understand that carry is well defined for ADDCARRY but my question is about SUBCARRY. Some architectures set the "carry" of a "x - y" subtraction is set when x < y (e.g x86, "borrow") and some others set it when x >= y (e.g. ARM). Does the ISD::SUBCARRY picks one interpretation (and uses it for combiners on top...