search for: instrinfo

When describing implicit register definitions for instructions in the InstrInfo.td file of a back end, what is the difference between using an 'implicit' node in the Pattern versus initializing the 'Defs' field? One difference seems to be that an 'implicit' node only comes into effect when the instruction is matched through the instruction's Patte...

The new SUBREG target-independent instructions aren't getting mayLoad/mayStore flags set correctly. For example, in the generated X86GenInstrInfo.inc file, there is only one entry for INSERT_SUBREG: { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, OperandInfo107 }, // Inst #5 = INSERT_SUBREG THe sixth field is zero, which means it doesn't have the the MayLoad flag set. x86-64 does have a few variants of...

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote: > The new SUBREG target-independent instructions aren't getting > mayLoad/mayStore flags set correctly. > > For example, in the generated X86GenInstrInfo.inc file, > there is only one entry for INSERT_SUBREG: > > { 5, 4, 1, 0, "INSERT_SUBREG", 0, 0, NULL, NULL, > OperandInfo107 }, // Inst #5 = INSERT_SUBREG > > THe sixth field is zero, which means it doesn't have the the > MayLoad flag set. I am...

Hi All, I am working on a target which requires to generated two instructions for a single branch instruction. ex: imm 1 br r4,0xabcd branch address is 0x1abcd, imm has the upper 16 bits and br has lower 16 bits. Can anyone let me know how to write these kind of patterns in the InstrInfo.td file. Thanks in Advance, Nagaraju

I think we can get rid of the TSFlagsFields and TSFlagsShifts hack in the InstrInfo TableGen class now. This seems to work just fine: class Instruction { bits<32> TSFlags; } class Domain<bits<2> val> { bits<2> Value = val; } def GenericDomain : Domain<0>; def SSEPackedInt : Domain<1>; def SSEPackedSingle : Domain<2>; def SSEPac...

...rget/Mips/CMakeLists.txt +++ b/lib/Target/Mips/CMakeLists.txt @@ -32,6 +32,8 @@ add_llvm_target(MipsCodeGen MipsLongBranch.cpp MipsMCInstLower.cpp MipsMachineFunction.cpp + MipsModuleISelDAGToDAG.cpp + MipsModuleISelLowering.cpp MipsRegisterInfo.cpp MipsSEFrameLowering.cpp MipsSEInstrInfo.cpp diff --git a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp index 00b3449..2ffd3a9 100644 --- a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp +++ b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp @@ -35,6 +35,11 @@ #include "llvm/Target/TargetMachine.h" using namesp...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...et wants this, we could add a ISD::RBIT operation, > it doesn't need to be added at the llvm ir level, The XCore also has ctlz and bitreverse instructions and not cttz. At the moment in the XCore backend cttz is marked as legal and expanded to this pair of instructions in a pattern in the InstrInfo.td. -- Richard Osborne | XMOS http://www.xmos.com

Hi all, I have defined an instruction in the InstFormat.td and InstrInfo.td files. I also wrote a CodeEmitter class for that, and now I have a .inc file after compilation that seems like it might be correct, BUT, I would like to see what will be generated when the assembly code is converted to the binary machine code! Is there any command in TableGen or a test class to...

HI developers, I want to add trigonometric instructions in my instrinfo.td files how can i directly map these instructions in .td files. Please help me Guys.For Sin, Cos, Tan and Cot Instructions. If I used llvm.sin.* as SDNode Then it is error as llvm variable is not defined SO please Help me. Thanks and Regards Varun -------------- next part -------------- An HTM...

....count", i32 1} !6 = distinct !{!6, !2} !7 = distinct !{!7, !4, !5} I get the following error: LLVM ERROR: Cannot select: t21: ch = store<ST64[%6](align=4)> t20, t19, t6, undef:i64 I don't understand why because it seems to me store is specified well in [MyTarget]InstrInfo.td . Can somebody help with an idea? Myself I will try to debug the code generated with TableGen, implementing the function SelectCode() . Best regards, Alex

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 (by calling setOperationAction with ISD::ADDE) but it didn't seem to reg...

Hello everyone! Is there any documentation about LLVM backend implementation, except "Writing an LLVM backend"? I'm trying to write InstrFormats.td and InstrInfo.td for my backend now. After reading "Writing an LLVM backend" and "Creating an LLVM Backend for the Cpu0 Architecture", many black holes have remained. These tutorials describe it on concrete examples, but general approach is missed. For example, how to implement different addr...

...re is no instruction for adding two i64s; it has to be done like this dst_high32:dst_low32 = src1_low32 + src2_low32 (unsigned add; dst_high might contain the overflow bit) dst_high32 = dst_high32 + src1_high32 dst_high32 = dst_high32 + src2_high32 I tried it with patterns like the following in InstrInfo.td (this is obviously wrong, but you have to start somewhere): def : Pattern<(set LLRegs:$dst, (add LLRegs:$src1, LLRegs:$src2)), [(set LLRegs:$dst, (anyext (add (trunc LLRegs:$src1), (trunc LLRegs:$src2))))]>; ... but tablegen complains: "Cannot use 'add' in an output patter...

...out any benefit is to define several intrinsics in the .td files, one for EACH possible string: // To put in the Intrinsics_....td file: def int_my_intrinsic1 : Intrinsic<[], [], []>; ... def int_my_intrinsicN : Intrinsic<[], [], []>; // To put in the InstrInfo.td file something like: def STR_PLACEHOLDER1 : ImmediateInstruction< 0b111111, (outs), (ins), "string_that_llc_codegen_should_output_as_assembly1",...

...iate is a label, in machine code the immediate is a relative offset for the PC). I have spent some time looking at the PPC and SPARC backends, but obviously these are much more complicated than what I require to implement. Consequently, I am not correctly grasping the interactions between ARCHInstrInfo.td and ARCHDAGToDAGISel.cpp I did manage to hack something together based on a copy of SPARC (with a SABRE namespace etc) but the instruction selection was incorrect and I obtained a "Cannot yet select:0x..." assertion failure from SABREDAGToDAGIsel::SelectCode when I attempted a llc...

I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). I've tried t...

...or some operations, say: ADD or1, ir1, r5 would add ir1 (input reg 1) and r5 and put the result in or1 (output reg 1). The point id that input and output regs have to go paired (this meaning an addition of ir1 with whatever always goes to or1, or an in general irX + whatever goes to orX). AFAIK, InstrInfo.td only allow "$src = $dst" type constraints. Is it possible to describe more complex src/dst relations, like the one I need? Also, I have tried making say or1 and ir1 parts of a single superreg (op1reg), using "$src = $dst" and a pattern to wrap the operations with EXTRACT_SUB...

...Load, 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...

...ear all, I would like to classify all target specific instructions in a set of categories. The category of each instruction would then be available in the backend. Just to illustrate what I am trying to do, the first thing I thought about how to achieve this was to group instruction definitions in InstrInfo.td in the order of categories, and to put pseudo instructions in between to mark category boundaries. However, the Target Instruction Enum in GenInstrNames.inc does not follow the definition order of the .td, but is in fact ordered alphabetically. Thanks for any suggestions! Christian...