similar to: [LLVMdev] At which point application vs target machine type width splitting happens?

Hello > I'm trying to understand how fitting source integer type width into > target machine register width happens. My reading on LLVM > codegeneration topics (few megabytes) so far didn't have this topic > mentioned explicitly. This is done during DAG Legalization phase. The operation is splitted into two (ADD + ADDC / ADDE). These DAG nodes are later matches during

Hello, On Fri, 22 Feb 2013 16:50:39 +0400 Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > > I'm trying to understand how fitting source integer type width into > > target machine register width happens. My reading on LLVM > > codegeneration topics (few megabytes) so far didn't have this topic > > mentioned explicitly. > This is

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

Hi, Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. Instructions are defined as follow in TableGen: defm ADD64 : ALU32<"add", 1, 1, addc>; defm ADD64C : ALU32<"addrc", 1, 2, adde>; Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to

The language I'm targeting doesn't have flags; I'd like to implement ADDE as a macro or psuedo-instruction that takes 3 parameters and returns 2. In my InstrInfo.td file, tablegen complains if I try to define multiple return values; adde is defined in TargetSelectionDAG.td to be a binary op that takes an extra flag in and sends an extra flag out. I tried to custom lower ADDE

On Mon, Oct 27, 2008 at 10:11 AM, Daniel M Gessel <gessel at apple.com> wrote: > The language I'm targeting doesn't have flags; I'd like to implement > ADDE as a macro or psuedo-instruction that takes 3 parameters and > returns 2. > > In my InstrInfo.td file, tablegen complains if I try to define > multiple return values; adde is defined in TargetSelectionDAG.td

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

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

guys, 1)i made a mistake in my post. the said TF node was created when Selected() was called in ADDC node. 2) the source code under test short a,b; void test() { a+=b; } 3)the DAG after ADDC was seleced: Select node: 0x4977a20: ch,glue = <<Unknown Machine Node #65419>> 0x4972bd0, 0x49731d0, 0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)> Result node: 0x4977a20: ch,glue =

I really have to force them to stuck together otherwise the carry will just not work. How about wrapping the 2 instructions in a bundle? Would that be a way? http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles On Mon, Apr 15, 2013 at 5:24 PM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi Francois, > > If you model the effect of your carry on the instructions, the

Legalizer will expand arithmetics using addc and adde. Is it not working for you? It works fine on x86, you can take a look how it's done. Evan On Sep 8, 2008, at 4:03 AM, Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out > the > magic. Here's

Thanks - that solves both problems. In the future, HW may have built in ADDE support, but will likely still not have flags - it'll just read 3 registers and write two. Any thoughts there? Thanks, Dan On Oct 27, 2008, at 12:07 PM, Andrew Lenharth wrote: > On Mon, Oct 27, 2008 at 10:11 AM, Daniel M Gessel <gessel at apple.com> > wrote: >> The language I'm

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

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

On Mon, Oct 27, 2008 at 11:15 AM, Daniel M Gessel <gessel at apple.com> wrote: > Thanks - that solves both problems. > > In the future, HW may have built in ADDE support, but will likely > still not have flags - it'll just read 3 registers and write two. > > Any thoughts there? Yes. What I think should happen is flags need to be less of a hack. There are two cases,

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

Hi, I am working on a LLVM backend that has eight different branch registers. I am having a lot of trouble with implementing the following instructions: addcg $r0.1, $b0.0 = $r0.1, $r0.1, $b0.0 (r is a general purpose register and b is a 1 bit branch register) The branch register is used for carry in and carry out. I have noticed that this instruction is very closely related to the ADDE

Evan Cheng wrote: > Legalizer will expand arithmetics using addc and adde. Is it not > working for you? It works fine on x86, you can take a look how it's > done. > > Evan The x86 has a carry bit, my target doesn't. It's not clear to me how I would specify the use of a general purpose register to contain the calculated carry in the current adde/addc scheme.

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

Hi Francois, If you model the effect of your carry on the instructions, the scheduler (and the other backend passes) should ensure that nothing that affects the carry will be inserted between your two instructions (assuming they are issued with nothing affecting the carry in between in the first place). Therefore, you shouldn’t have to force them to be stuck together. If you still do, what Jakob