similar to: [LLVMdev] Pattern-matching a MOV instruction

Hi, I am trying to do a backend to a very simple microcontroller. I have some questions. 1) I have instruction which do "r1 <- r1 op r2", from what I have ssen I must declare them like: let isTwoAddress = 1 in def ADD : FopRR< 0b01010, (outs CPURegs:$sX), (ins CPURegs:$isX, CPURegs:$sY), "ADD $sX, $sY"), [(set

On Apr 27, 2008, at 7:37 AM, Cédric Venet wrote: > Hi, > > I am trying to do a backend to a very simple microcontroller. I have > some > questions. Ok. > 1) I have instruction which do "r1 <- r1 op r2", from what I have > ssen I > must declare them like: > > let isTwoAddress = 1 in > def ADD : FopRR< 0b01010, > (outs

I have a target backend which is currently causing live interval analysis to throw 'Interval not live at use' errors for many of my benchmarks. I imagine that this is caused by missing information for my target (probably in the instructioninfo tablegen?), but I am having difficulties in both debugging and fixing this problem, and would appreciate any advice or help anyone can give.

Hi all, I'm trying to create a new backend for a processor, and I start with modifying the existing backends like MIPS and Microblaze. I have a problem when I try to add a register class in the Target's register description, it looks like this: def IGPRegs : RegisterClass<"MBlaze", [v8i16], 128, [PR0, PR1, PR2, PR3]>; // PR0 - PR3 are registers defined before I want to

I believe that table gen builds MipsGenAsmMatcher.inc which has the Match routines like MatchRegisterName(). In building MipsGenAsmMatcher.inc I am hitting the following issue (actually several, but they may be related). It may have something to do with the $$ escape sequence: /home/jcarter/workarea/llvm/lib/Target/Mips/Mips64InstrInfo.td:173:1: error: error: unable to find operand:

Thanks for the suggestion. I ran verify-machineinstrs and found that I've definitely been doing something wrong, for quite a while at least (I assume that live interval analysis and the particular benchmark just happened to expose it). Results are at http://pastebin.com/5zeUDVXK. I'm not entirely sure what is wrong here - I assume it has something to do with my 'special'

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallthrough // conditional branch.

For my target, I handle incoming memory arguments by creating a store to memory (in LowerCall, [1]), then creating a fixed object on the stack and loading from it (in LowerFormalArguments[2]). This approach was based on MSP430. I now have the problem that the resulting loads in my output assembly are done assuming that the call stack looks something like: ------ MemArg ------ MemArg ------

Are there any other patterns in your TD file? If so, then one of the ones before this pattern will match everything, and this pattern will never be matched. -bw On Jul 3, 2009, at 8:27 PM, Javier Martinez wrote: > Hello, > > I'm new to LLVM and I'm using it to translate from LLVM to another > language rather than emitting actual machine code. The target language > has

Hello, I'm new to LLVM and I'm using it to translate from LLVM to another language rather than emitting actual machine code. The target language has instructions that operate on pointers which aren't naturally exposed in LLVM. Here's what I've done to add pointer support for an instruction called PADD that takes a pointers and an offset and returns the new pointer value:

Hi, I'd like to understand the order in which patterns are searched during ISEL. In the example below, indices are searched in ascending order from 808 to 3305, then it goes back to 3259 and eventually it matches the wrong instruction. Why did go back from 3305 to 3259? In my XXXGenDAGISel.inc, I can see that the correct instruction is at index 3420 but it never got there. ISEL: Starting

I discovered I needed: Index: lib/CodeGen/TwoAddressInstructionPass.cpp =================================================================== --- lib/CodeGen/TwoAddressInstructionPass.cpp (revision 71041) +++ lib/CodeGen/TwoAddressInstructionPass.cpp (working copy) @@ -935,6 +935,7 @@ ++NumReMats; } else { bool Emitted = TII->copyRegToReg(*mbbi, mi, regA,

That's kind of strange. It might be some type of "default". However, you probably don't want to turn off the "commutative" property, unless it really isn't commutative. I know it's painful, but it might be best just to slog through the TableGen code in a debugger, and see why it is that your stuff inherits properties from the ADD in

Hi Bill, Yes, there are other patterns. I tried commenting out all the other instructions definitions and I still get this error. After debugging TblGen I found that the second pattern is being generated as a variant of the first. I think the reason is that the PADD instruction is inheriting the commutative property from ADD defined inTargetSelectionDAG.td. The variant ends up being the same

I'm trying to add support for inline assembly and I keep getting this error: <jal> "<inline asm>:1:2: error: invalid instruction" which is due to the fact that MatchInstructionImpl() returns Match_MnemonicFail. This function is tablegen'ed in XXXGenAsmMatcher.inc and for some reason it can't find JAL even though I can clearly see it in both MatchTable0[] and

Hello David, Thanks for your example. Is that means that DAG pattern is consist of LLVM IR instruction?? I met an example [(set CPURegs:$dst, (OpNode CPURegs:$b, CPURegs:$c))] of MipsInstrInfo.td, but I can't find correspond LLVM IR instruction of "set" in "LLVM Language Reference Manual". Is that correspond to $dst = op $b, $c?? Would you mind to tell me whether there is

Hi, It seems to me that the TwoAddressInstructionPass::runOnMachineFunction method has some problems when the tied destination register has a subReg. The two changes below improves the situation for me but I'm all new to this so I'm not sure how it's supposed to work. I'm running on 2.9. Any comments? @@ -1172,12 +1172,20 @@ bool

Dan Gohman wrote: > On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: > >> Because sextb_r and sextw_r have destination tied to source operands, >> TwoAddressInstructionPass thinks it needs a copy. However, since the >> sext kills its source, the copy is unnecessary. Why does this happen? >> Is TwoAddressInstructionPass relying on a later pass to notice this

So what is the status about LiveVariables. Is there a plan to remove it? After searching in old lvm-dev-mails it is mentioned that LiveVariable still exists due to one pass needing it. And a comment in TargetPassConfig.cpp indicates that the pass in question is TwoAddressInstruction: // FIXME: Once TwoAddressInstruction pass no longer uses kill flags, // LiveVariables can be removed

On Apr 21, 2009, at 4:02 PM, Greg McGary wrote: > Dan Gohman wrote: >> On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: >> >>> Because sextb_r and sextw_r have destination tied to source >>> operands, >>> TwoAddressInstructionPass thinks it needs a copy. However, since >>> the >>> sext kills its source, the copy is unnecessary. Why