search for: rsrc1

...m not clear on why that's the case. This isn't just the results of instructions, but also immediate values as well. It seems to affect a smattering of node types. Any insights? For instance: where GPRegs contains types [i32, f32] def BEQ : IF8<Opc.BEQ, (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), "beq $Rsrc1, $Rsrc2, $SImm16", [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: $SImm16)], s_br>; Tablegen reports: BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2, SETEQ:Other), (bb:Other):$S...

...gt; This isn't just the results of instructions, but also immediate > values as well. It seems to affect a smattering of node types. Any > insights? > > For instance: > > where GPRegs contains types [i32, f32] > > def BEQ : IF8<Opc.BEQ, > (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), > "beq $Rsrc1, $Rsrc2, $SImm16", > [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: > $SImm16)], s_br>; > > Tablegen reports: > BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2, &gt...

...to match rather than silently producing an incorrect GenCodeEmitter. class MyFormat<bits<32> OpcVal, dag ops, string asmstr, list<dag> pattern, InstrItinClass itin> : MyInst<ops, asmstr, pattern, itin> { let Inst{31-28} = OpcVal{31-28}; bits<6> Rsrc1; <===== Because destination is required first in operand ordering, bits<6> Rdest; <===== this ordering of declarations produces an incorrect GenCodeEmitter bits<16> Imm16; let Inst{27-22} = Rsrc1; let Inst{21-16} = Rdest; let Inst{15-0} = Imm16; } def ORI : My...

...of instructions, but also immediate >> values as well. It seems to affect a smattering of node types. Any >> insights? >> >> For instance: >> >> where GPRegs contains types [i32, f32] >> >> def BEQ : IF8<Opc.BEQ, >> (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), >> "beq $Rsrc1, $Rsrc2, $SImm16", >> [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: >> $SImm16)], s_br>; >> >> Tablegen reports: >> BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1...

...This isn't just the results of instructions, but also immediate > values as well. It seems to affect a smattering of node types. Any > insights? > > For instance: > > where GPRegs contains types [i32, f32] > > def BEQ : IF8<Opc.BEQ, > (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), > "beq $Rsrc1, $Rsrc2, $SImm16", > [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: > $SImm16)], s_br>; > > Tablegen reports: > BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32: > $Rs...

On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > I noticed that the TableGen code emitter generator assumes that the > instruction fields are declared in the instruction format in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to determine which operand of the MI to use . See

...4, 2017 at 8:22 PM, Sean Silva <chisophugis at gmail.com> wrote: > I'm having a hard time grasping what this ISA actually looks like. > > When you say that it has a single instruction that is a majority function, > I assume something like this: > > MAJ rDst <- rSrc0, rSrc1, rSrc2 > Semantics: > for (int i = 0; i < REGISTER_WIDTH; i++) { > rDst[i] = maj(rSrc0[i], rSrc1[i], rSrc2[i]); > } > Where maj(a, b, c) = (a & b) | (a & c) | (b & c) > > But that doesn't make sense given your question. > > MAJ is a bitwise operation,...

...multiply-and-accumulate. The result goes into a special register that can destructively read at the end of a sequence of multiply-adds. The following sequence is required to so a simple multiply: acc r0 # clear accumulator, discarding its value (r0 reads as 0, and sinks writes) mac rSRC1, rSRC2 # multiply sources, store result in accumulator acc rDEST # fetch accumulator value to rDEST What's the best way to model simple MUL as this 3-insn sequence in the LLVM backend? Should the internal accumulation register be explicitly modeled as its own register class with a p...

Hello everyone, I was trying to create an LLVM backend for a processor with a very simple architecture and that does all instructions like load, store, arithmetic and logical instructions using a bunch of majority functions. The processor has only one instruction(majority function) in its ISA and breaks down all other instructions into a number of majority instructions depending on what

.... The result goes into a special register that > can destructively read at the end of a sequence of multiply-adds. The > following sequence is required to so a simple multiply: > > acc r0 # clear accumulator, discarding its value (r0 reads as 0, > and sinks writes) > mac rSRC1, rSRC2 # multiply sources, store result in accumulator > acc rDEST # fetch accumulator value to rDEST > > What's the best way to model simple MUL as this 3-insn sequence in the > LLVM backend? > > Should the internal accumulation register be explicitly modeled as its &g...