search for: geninstrinfo

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint does not appear anywhere in source/lib/Target/X86/* yet TIED_TO occurs in 162 of the OperandInfo's in build/lib/Target/X86/X86GenInstrIn...

...s not the way it worked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc lib/Target/ARM/ARMGenInstrInfo.inc:727 lib/Target/X86/X86GenInstrInfo.inc:920 I don't think more than half of those UnmodeledSideEffects flags should be there. I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitio...

...mayLoad, do these instructions have patterns? Tablegen can infer > mayLoad/mayStores/hasSideEffects from patterns so it doesn't always > need to be listed explicitly in the td files. Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInstrInfo.inc file directly. I find this much easier. In theory, we'd like to move away from the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). -Hal...

...e patterns? Tablegen can infer >>> mayLoad/mayStores/hasSideEffects from patterns so it doesn't always >>> need to be listed explicitly in the td files. >> >> Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInstrInfo.inc file directly. I find this much easier. In theory, we'd like to move away from the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). > &...

...gt;>>>> mayLoad/mayStores/hasSideEffects from patterns so it doesn't always >>>>> need to be listed explicitly in the td files. >>>> >>>> Having recently audited these flags in the PowerPC backend, I highly recommend looking at these from the *GenInstrInfo.inc file directly. I find this much easier. In theory, we'd like to move away from the pattern-based flag inference. Once a target is free of dependence on the inference rules, it can set bit guessInstructionProperties = 0; to turn them off completely (see class InstrInfo in Target.td). >&gt...

...ked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very...

.../%GenInstrNames.inc.tmp): \ $(ObjDir)/%GenInstrNames.inc.tmp : %.td $(ObjDir)/.dir $(Echo) "Building $(<F) instruction names with tblgen" - $(Verb) $(TableGen) -gen-instr-enums -o $@ $< + $(Verb) $(TableGen) -gen-instr-enums -o $(call SYSPATH, $@) $< $(TARGET:%=$(ObjDir)/%GenInstrInfo.inc.tmp): \ $(ObjDir)/%GenInstrInfo.inc.tmp : %.td $(ObjDir)/.dir $(Echo) "Building $(<F) instruction information with tblgen" - $(Verb) $(TableGen) -gen-instr-desc -o $@ $< + $(Verb) $(TableGen) -gen-instr-desc -o $(call SYSPATH, $@) $< $(TARGET:%=$(ObjDir)/%GenAsmWriter...

...x2f566b0: i32 = fp32_to_fp16 0x2f66bb0 [ID=876] So I created an instruction pattern which matches this fp32_to_fp16 def CFHrf : InstTCE<(outs R32IRegs:$op2), (ins R32FPRegs:$op1), "", [(set R32IRegs:$op2, (fp32_to_fp16 R32FPRegs:$op1))]>; But then I got error /tmp/tcecc-dKBdca/GenInstrInfo.td:30:91: error: Variable not defined: 'fp32_to_fp16'

...ked out. It is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very...

...It is often more convenient to use def : > Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often > forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be > there. > > > I want to stop inferring instruction properties from patterns in TableGen. > It has beco...

Having worked with a few people to better understand the tablegen descriptions of instructions and patterns in LLVM's backend and looking at x86's pretty heavily, I have some questions: 1) Are there instruction definition flags that are really just "when needed"? I'm thinking of things like "mayLoad" which is really alarmingly missing from a bunch of instructions

...heckANDW, CheckANDX, CheckCOPY]>>; ``` TIIPredicate definitions are used to model calls to the target-specific InstrInfo. A TIIPredicate definition is treated specially by the InstrInfoEmitter tablegen backend, which will use it to automatically generate a definition in the target specific `GenInstrInfo` class. Basically, we can tell tablegen to generate that definition for us. Now that the description of IsGPRZero is available in the form of a MCPredicate, we can modify the original SchedWriteVariant WriteImmZ as follows: ``` def WriteZPred : MCSchedPredicate<IsGPRZero>; def WriteImmZ :...

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron