similar to: [LLVMdev] IMPLICIT_DEF's

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

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

Dear guys, I want to coalesce some copies, and I would like to know if there is any method that I can call, like JoinCopy from the old (LLVM 1.9) LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM 2.1), but I do not want to call this analysis, as I have my own. basically, I can determine that two virtuals do not overlap, and I know that it is safe to join them. In

> Why do you want to do this? Empty MBBs are valid, and it's probably > better to have your code handle them. Currently, that is the solution. I have a special treatment for empty basic blocks. I think the code would be more homogeneous if there were no empty basic blocks. > > There is a NOP "instruction" on x86, equivalent to XCHG EAX, EAX. The problem with xchk

Dear guys, I am in need of more of your help. I'm implementing a register allocator, and I am having problems to make it produce correct code. Consider this program here: int main(int argc, char ** argv) { int i, j, sum; i = argv[0][0]; j = argv[0][1]; sum = (i + j) * j; printf("Sum = %d\n", sum); } that maps to this llvm bytecode: entry (0xa785590, LLVM

I was using them to do SSA-elimination after register allocation. I can implement swaps using three XOR's, but then the code becomes a little bigger and slower. I think even for the sake of completeness, the X86 back-end should offer the possibility of swapping two registers with one single instruction. Do you guys think there is any possibility that those instructions could come back to

On Dec 15, 2007, at 4:45 PM, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I want to coalesce some copies, and I would like to know if > there is > any method that I can call, like JoinCopy from the old (LLVM 1.9) > LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM > 2.1), > but I do not want to call this analysis, as I have my own.

Hi, guys. sorry if this has already been discussed, but I still feel like clarifying: how should the register allocator handle IMPLICIT_DEF instructions? The LiveIntervalAnalysis class is assigning them zero length intervals. After I removed this, e.g, by removing the lines: if (mi->getOpcode() == TargetInstrInfo::IMPLICIT_DEF) { DOUT << "is a implicit_def\n";

Dear Dave, Evan, thank you for answering. What I did was to remove the implementation of most of the methods of SimpleRegisterCoalescing and put them in a single class (RegisterCoalescer_Impl) that is not an analysis. Any class that wants these methods, can extend this class privately, or can use a reference to an RegisterCoalescer_Impl object. I wish it would be possible to go even

Dear LLVM'ers, in my register allocator, sometimes I have to spill virtuals that represent the same variable before SSA conversion. I would like to assign the same stack slot to these virtuals. Is there a way to recover this information from one of LLVM data structures? In other words, is it possible to discover which virtuals represent the same variable before SSA conversion by reading

Hi, again, I think you can do it in the same way that the other allocators have been coded, i.e extend RA, register the pass and so forth. I am not sure about the best way to pass information among a run of RegAlloc to the other, maybe the other guys in the list could suggest something. Yet, you can always dump it into a file, and read it again, everytime it is necessary. Remember that

Thanks again. One more question here: Since the regalloc works once per function, do I stil have access to the Call graph? Just saving information between regalloc passes for different functions may not be enough for my case. I will need to maintain the regalloc info of various passes in the call graph order. Anyways thanks for your inputs. I will get back if I need to learn more. Sanjiv On Nov

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >> I'm definitely interested in improving coalescing and it sounds like >> this would fall under that work. Do you have references to papers >> that talk about the various algorithms? > > Some suggestions: > > @InProceedings{Budimlic02, > AUTHOR = {Zoran Budimlic and Keith D. Cooper and Timothy

>> I've built a pass to split critical edges of machine functions, and I have >> to insert new basic blocks. Some of them will have MBB->begin() == >> MBB->end(). > > Ah, machine basic blocks are different. They *are* allowed to be empty. > I would like to build an "insertNoOp" and add it to MRegisterInfo. I would have one for each target. For the

Hey all, is there a simple way to alternate between different register allocators at run time? I would like to decide dynamically which register allocator to use. The decision is based on information that is produced by a pass that executes before register allocation takes place. Is it possible to modify RegisterRegAlloc::Registry to take into consideration this information? Is there

Dear llvmers, I am trying to insert a move instruction where both source and destination registers are physical registers. How is the code for this? I tried this one here: void PhiDeconstruction_Fer::add_move ( MachineFunction & mf, MachineBasicBlock & mbb, unsigned

On Sun, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > } > > But the getRegClass method seems to

I would like to make a suggestion. In the LiveIntervalAnalysis class, instead of numbering the instructions in the order in which basic blocks are stored in the machine function, use the df_ext_iterator. It will order the instruction according to the dominance tree (or it seems to be doing so). There are many advantages in doing this. One of them is that, once you traverse the dominance tree

Hi Florian, we though about using UIUC, like in LLVM. Do you guys know if that could be a problem, given that we are mining the functions from github? > Have you thought about integrating the benchmarks as external tests into LLVM’s test-suite? That would make it very easy to play around with. We did not think about it actually. But we would be happy to do it, if the community accepts