similar to: Deprecating ADDC/ADDE/SUBC/SUBE

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

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

On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote: > 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

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

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

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

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

I don't think that'd work, because it leaves all other backends broken. AFAICT, your transform is simply not a legal 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

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 all, As you knwo already, I'm trying to change DAGCombiner so that it process the nodes in topological order. Doing so is not difficult per se, but this creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time. One source of such regressions is combineIncDecVector in the X86 backend. It

Hi Tom, Matt, I'm running into strange issues with the cos test (piglit generated_tests/cl/builtin/math/builtin-float-cos-1.0.generated.c) I have been seeing random failures (incorrect results) for some time and tried to investigate. the weird part is that the failures are not 100% reproducible, sometimes the tests pass, or partly pass (it's usually float8 and float16 subtests that

Hi all, It looks like I ended up reviewing most C API patches over the last few years. There's currently no code owner listed for the C API. I'd like to take it so that contributors know to tag me as a reviewer. Any objections? -- whitequark

No objections from me to make it run later. I didn't see the potential conflicts when I added that code. Delayed combine, custom lowering, or DAGToDAGISel all seem like viable options to me. On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > I have previously posted these two patches: > > [X86][CodeGen][NFC] Delay `combineIncDecVector()` from

Hi all, We quickly talked with whitequark on IRC about this. I think he makes a good candidate. I also wrote and reviewed a lot of code in there, so if that's needed I can be in there. In any case, I voutch for whitequark. Amaury Séchet 2018-04-12 0:54 GMT+02:00 whitequark via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all, > > It looks like I ended up reviewing most C API

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

I think DAGToDAG is too late because the build_vector has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1. +Sanjay as well From: Amaury Séchet <deadalnix at gmail.com> Sent: Monday, August

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

Long story short: https://llvm.org/bugs/show_bug.cgi?id=31890 The backend fails to schedule a given DAG, the reason being that there is an instruction and it glue that needs to be broken apart as they can't be scheduled consecutively. See attached file for a picture of the DAG. Not sure what's the best course of action is, and not sure why this isn't a problem for the X86 backend

Hey ppl ! My WinXP workstations are not able to join my domain. I tried to apply the registry fix for plain-text passwords but it has no effects :( My PDC seems to work fine cause i've got no problems with Win2K Workstations... Is there anything i've omitted ? Regards, Amaury -------------- next part -------------- HTML attachment scrubbed and removed

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010 at 2:19 PM, Amaury