search for: regconstraint

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores). > For example: the defi...

On Sun, 28 May 2017, David Chisnall wrote: >> let Constraints = "@earlyclobber $reg" in >> def LDWRdPtr : Pseudo<(outs DREGS:$reg), >> (ins PTRREGS:$ptrreg), >> "ldw\t$reg, $ptrreg", >> [(set i16:$reg, (load i16:$ptrreg))]>, >>

...cessarily a separate register). The FMA variants have patterns in the .td file because they don't have multiple results - they just have one of their operands being both an input and an output. So the idea is that you specify your `outs` in the instruction definition, one of those will have a `RegConstraint` on them and finally, you emit these nodes in your <TargetName>ISelDAGToDAG.cpp. On Tue, May 30, 2017 at 3:01 PM, Dr. ERDI Gergo <gergo at erdi.hu> wrote: > On Tue, 30 May 2017, Nemanja Ivanovic wrote: > > This is typically accomplished with something like PPC's `RegConst...

My bad for not looking further. I'm still somewhat confused though. MOVCCr gets expanded in the ARMExpandPseudoInsts pass, and it still seems only a case of one instruction replacing the other. My worry of emitting two instructions, is that a dead code pass will eliminate the first instruction cause it thinks the second instruction is defining the same register. -Dilan On Fri, Jul 7, 2017

...out the ptr_rc: references like so: -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: $addr), +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins memri:$addr), "lbzu $rD, $addr", LdStLoadUpd, []>, RegConstraint<"$addr.reg = $ea_result">, NoEncode<"$ea_result">; I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". I.e.: llvm[3]: Building PPC.td instruction information with tblgen STBU: (set ptr_rc_wrapper:<empty>:$ea_res...

Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher

...rand must be the same as some output operand. For example, the PowerPC backend has a pre-increment store encoded like this: def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), "stdux $rS, $dst", LdStSTDU, []>, RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; } def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), (STDUX $rS, $ptrreg, $ptroff)>; Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are c...

...as some output operand. For example, the PowerPC backend has a pre-increment store encoded like this: > > def STDUX : XForm_8<31, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), > "stdux $rS, $dst", LdStSTDU, []>, > RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; > } > > def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), > (STDUX $rS, $ptrreg, $ptroff)>; > > Note that the instruction has a pseudo-output operand $ea_res which is constrain...

Hi Hal, Our Architecture has indirect move instruction which increments the pointer implicitly and the target only has i8 type values. So the load of i16 will be converted to two i8 target loads wherein after the first load instruction, the pointer to the first i8 address will automatically increment to point to the next i8 value. So the post increment nature is in the Target. A normal

...two-value operand where a dag node expects two operands. :( let neverHasSideEffects = 1 in { def MOVCCr : ARMPseudoInst<(outs GPR:$Rd), (ins GPR:$false, GPR:$Rm, pred:$p), 4, IIC_iCMOVr, [/*(set GPR:$Rd, (ARMcmov GPR:$false, GPR:$Rm, imm:$cc, CCR:$ccr))*/]>, RegConstraint<"$false = $Rd">; It would appear that ISelDAGToDag and ISelLowering have "knowledge" of the CCR, but ... I'm wondering if that's a moot point since the instruction definitions could care less. K, well I guess I get to learn more about the DAG data model in LLVM....

...> My bad for not looking further. I'm still somewhat confused though. > > MOVCCr gets expanded in the ARMExpandPseudoInsts pass, and it still > > seems only a case of one instruction replacing the other. > > The output of MOVCCr is tied to the "false" input using RegConstraint. > The register allocator puts the "false" value into the destination > register, then MOVCCr gets expanded to a predicated MOVr which moves the > "true" value into the destination register. > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. &...

...> > -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: > $addr), > +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins > memri:$addr), > "lbzu $rD, $addr", LdStLoadUpd, > []>, RegConstraint<"$addr.reg = $ea_result">, > NoEncode<"$ea_result">; > > > I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". > I.e.: > llvm[3]: Building PPC.td instruction information with tblgen > STBU: (set p...