similar to: [LLVMdev] Callee saved register, almost

Vladimir Prus wrote: > I've another problem. There's one register, gr6, which is used to return > high part of return value for functions returning 64-bit values. For such > functions, the register should not be saved, naturally. > > But when function does not return 64-bit value, then the register must be > saved. How can I express this in .td file? Ok, I've managed

Alkis Evlogimenos wrote: > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > Hello! > > Is there an (semi)automatic way to save registers used by a function? For > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > now I just emit huge prologue code to push them all to stack -- even if > > they are not modified at all. > > >

On Tue, 22 Jun 2004, Vladimir Prus wrote: > First, I attach two files -- LLVM asm and the asm for my target. The problem > with assembler is: on line 171 it uses register gr2, which is copied from gr6 > above, on line 161. The only predecessor of this basic block is jump on line > 90. The problem is that gr6 is not initialized in the interval from the > function entry till the

Folks, I'm running into something which looks like a bug in linearscan allocator. Of course I can't be 100% sure it's not some unobvious mistake on my part, so I'd like to hear your opinion. First, I attach two files -- LLVM asm and the asm for my target. The problem with assembler is: on line 171 it uses register gr2, which is copied from gr6 above, on line 161. The only

Hello! Is there an (semi)automatic way to save registers used by a function? For example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For now I just emit huge prologue code to push them all to stack -- even if they are not modified at all. Is there a way to tell LLVM which registers must be stored, and have it automatically issue pushes/pops? I can live with current design,

On Wed, 2004-06-09 at 05:26, Vladimir Prus wrote: > Alkis Evlogimenos wrote: > > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > > Hello! > > > Is there an (semi)automatic way to save registers used by a function? For > > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > > now I just emit huge prologue code to push

On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > Hello! > Is there an (semi)automatic way to save registers used by a function? For > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For now > I just emit huge prologue code to push them all to stack -- even if they are > not modified at all. > > Is there a way to tell LLVM which registers must be

On my target, the multiplication can involve all general purpose registers, but there's are still some restrictions: the first and the second operand as well as the result must be in different registers, and neither register can be gr7. How can I enforce this restriction on the register allocator? - Volodya

Chris Lattner wrote: > On Tue, 22 Jun 2004, Vladimir Prus wrote: > > First, I attach two files -- LLVM asm and the asm for my target. The > > problem with assembler is: on line 171 it uses register gr2, which is > > copied from gr6 above, on line 161. The only predecessor of this basic > > block is jump on line 90. The problem is that gr6 is not initialized in > >

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

While adding support for branch instructions in my backend, I run into a trouble. The code to handle branches looks like: void visitBranchInst(BranchInst& BI) { BB->addSuccessor (MBBMap[BI.getSuccessor(0)]); if (BI.isConditional()) BB->addSuccessor (MBBMap[BI.getSuccessor(1)]); ........... BuildMI(BB,

Hello, I'm considering a possibility of writing an llvm backend for my research uses. Unfortunately, I can't find much information on how do to it. I more or less understood now the C backend is implemented, but for real backend I'd need at least register allocation. I beleive there's already register allocator in LLVM and I would like to reuse it if possible. The question is

Hi, in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' parameter, that is not documented. Can somebody explain what does it mean? Thanks, Volodya

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >> in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' >> parameter, that is not documented. >> >> Can somebody explain what does it mean? > > Basically, it gives the target more information about the spill. In > particular, it specifies the register class to use

On Sat, 13 May 2006, Vladimir Prus wrote: > in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' > parameter, that is not documented. > > Can somebody explain what does it mean? Basically, it gives the target more information about the spill. In particular, it specifies the register class to use for the copy. The target can choose to ignore this if it

Hi Chris, >> It is marked callee saved. Because when it is not needed as frame >> pointer it is used like an ordinary register. But when it is used as >> frame pointer, the prologue and epilogue change its value, but the >> algorithm in llvm that finds clobbered register does not select it. >> > > Okay, I'm not sure. If you describe the constraints

Hello, I'm getting an assertion in register allocator, specifically in LiveIntervalAnalysis.h, method LiveIntervals::getInstructionIndex: unsigned getInstructionIndex(MachineInstr* instr) const { Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); assert(it != mi2iMap_.end() && "Invalid instruction!"); return it->second; } The crash happens

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

Hello, Arnold. > Is there a way to indicate that the register the tail call > instruction uses as destination needs to be valid after the callee > saved registers have been restored? (some X86InstrInfo.td foo magic > maybe ?) It's wrong way to do the things. Because in this case you either violate the ABI for callee, or you're restricted to do tail call lowering only for

The docs for the above-mentioned function say: This method may modify or replace the specified instruction, as long as it keeps the iterator pointing the the finished product. What does it mean to "keep an interator". Was "invalidates the iterator" intended, so something else. Another question, is how do I really replace the instruction. The operator= is private