similar to: [LLVMdev] IMPLICIT_DEF's

Guys, I think I figure out the way that the current LLVM allocators are handling IMPLICIT_DEF's. One question more: why are you adding null length intervals to IMPLICIT_DEF instructions? If they were non-null, I think the code to handle them would be more homogeneous, e.g a traversal of the intervals during register allocation would already reveal virtuals defined implicitly. best,

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

Hi Mikaël, Thanks for the patch. Some comments: 1. Please don't use tabs. 2. Index: lib/Target/ARM/ARMInstrInfo.cpp =================================================================== --- lib/Target/ARM/ARMInstrInfo.cpp (revision 14) +++ lib/Target/ARM/ARMInstrInfo.cpp (working copy) @@ -904,7 +904,8 @@ return TAI->getInlineAsmLength(MI-

Hi, This pass is similar to the one in BreakCriticalEdges.cpp, but it works for MachineFunction's, instead of Functions. The existence of critical edges complicates many optimizations. When doing register allocation, you don't necessarily have to remove critical edges (you can use conventional SSA-form, for instance. See "Translating Out of Static Single Assignment Form. SAS

> > How about a default GetInstSize() as well? Return 1 for every > instruction except for some special TargetInstrInfo instructions, e.g. > PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But > perhaps we can default most targets to it? > > I prefer not giving a default implementation and aborting with a message that says the target did not

On Apr 16, 2008, at 1:46 AM, Nicolas Geoffray wrote: > >> >> How about a default GetInstSize() as well? Return 1 for every >> instruction except for some special TargetInstrInfo instructions, >> e.g. >> PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But >> perhaps we can default most targets to it? >> >> > > I

Thanks, Evan. Actually I've solved my problem with some hints from Dale and Anton. At least I think I've solved it. I had to add one method to TargetInstrInfo to tell me when an instruction is an indirect jump - TargetInstrInfo::tii.isIndirectJump(opcode). When that is the case, I update the jump table using: // Change jumps to go to the new basic block:

On Aug 17, 2007, at 3:08 PM, Fernando Magno Quintao Pereira wrote: > > Thanks, Evan. > > Actually I've solved my problem with some hints from Dale and > Anton. Ok, cool. I didn't see their replies. Like I said, my email client is acting funny. > At least I think I've solved it. I had to add one method to > TargetInstrInfo to tell me when an instruction

Dear guys, I am having problem to split edges correctly. Mostly because the new basic blocks are creating infinite loops. Could someone help me fixing the code below? It is creating assembly like this one below. Block LBB1_9 was inserted to break the critical edge between blocks LBB1_3 and LBB1_8. But it changes the semantics of the original program, because, before, LBB1_8 was falling

The problem is that you are inserting block 9 in the wrong spot. mf.getLastBlock() returns the block with the greatest number which may have nothing to do with the ordering. Why not use the end iterator (mf.end) to insert? -Tanya On Sat, 8 Jul 2006, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I am having problem to split edges correctly. Mostly because the new

On Mon, 14 Aug 2006, Fernando Magno Quintao Pereira wrote: > I reload spilled code. If I am doing something evidently wrong, I would > appreciate if someone tells me. With the comment on vrm->virtFolded, I am > passing all the tests that I have. I haven't had a chance to look at the code you have below, but I would guess that you are leaving a dangling pointer in some map

Hi, guys, What is the opcode of the instruction to swap two registers in X86? After updating my LLVM branch, I realized that there is no longer an opcode for xchg with two register operands in X86GenInstrNames.inc. I found only instructions to swap memory and registers: XCHG16rm, XCHG32rm, XCHG64rm and XCHG8rm. I am updating from LLVM 2.1 to current trunk. The names that I was

Sorry about the tardiness of my reply. My mail client has playing tricks with me. :-) I am assuming the issue has nothing to do the branch to jumptable instructions but rather the MachineJumpTableInfo associated with every MachineFunction? If so, please take a look at BranchFoldiing.cpp for an example. Evan On Aug 10, 2007, at 12:30 PM, Fernando Magno Quintao Pereira wrote: > >

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

Fernando, The code there should be more or less functional, though it's not currently used by anything. Eventually it should probably be moved to a method on MachineBasicBlock. The API breakage you're seeing is because some methods moved around. Feel free to fix it. :-) --Owen On Jan 26, 2008, at 6:31 PM, Fernando Magno Quintao Pereira wrote: > > Hi LLVMers, > >

Hi LLVMers, what is the status of breaking critical edges in machine functions? I just compiled the top of the LLVM tree, and I found llvm/CodeGen/BreakCriticalMachineEdge.h. But this file seems not to be up-to-date with the other classes in the top of the tree. For instance, it calls isTerminatorInstr on llvm::TargetInstrInfo, but this method is no longer there. If I want to break

Hi all, I have a pass to break critical edges of Machine Basic Blocks, but I just discovered a bug (when compiling code for x86). The problem is 'jumpl *%reg'. I don't know how to update the jump table for this type of instruction. The code that I had (see below) does not update the jump table, and the actual branch keeps jumping to the old basic block, instead of the new.

On Jul 20, 2008, at 11:50 AM, Fernando Magno Quintao Pereira wrote: > I am updating from LLVM 2.1 to current trunk. The names that I was > using > in LLVM 2.1 were: XCHG8rr, XCHG16rr, XCHG32rr and XCHG64rr. > > Ps.: Evan, thank you for answering the question about IMPLICIT_DEF's. I think they were removed just because noone was using them. Also, the JIT encoding may have

> Hi Fernando, > > It's hard to say exactly what's happening because I don't know your > code (though, from the stack trace, it seems like there's some sort > of memory debacle), but looking at the comment in the > LiveVariableAnalysis.cpp file where it's folding memory operands, it > might explain somethings better: > > // Folding the

On Aug 13, 2006, at 11:16 PM, Fernando Magno Quintao Pereira wrote: > > Dear LLVMers, > > I am trying to fold memory operands in the way that is done in > RegAllocLocal.cpp, or in LiveIntervalAnalysis.cpp, but I am getting > errors > that > I don't know how to fix. Could someone tell me which steps should I > take > in order > to correctly fold memory