search for: getreservedregs

Hi, I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one that *has particular uses and should be considered unavailable at all times. *If it is unavailable at all times, why not make such a reserved register unallocatable? Thanks! Regards, Lei Mou -------------- next part -------------- An HTML attachment was scr...

...: > I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one that has particular uses and should be considered unavailable at all times. If it is unavailable at all times, why not make such a reserved register unallocatable? Thanks! Registers are partitioned into three disjoint sets: 1. Allocatable registers. 2. Res...

> It does, but you can dynamically reserve registers. So, if I'm understanding this correctly, the approach would then be to use a large upper bound on the number of registers (the instruction encoding limits it to 256, so that is safe), and then say "don't use registers [N,256)" in order to effectively codegen for registers [0,N)? Also, could you provide me some pointers to

...ruction > encoding limits it to 256, so that is safe), and then say "don't use > registers [N,256)" in order to effectively codegen for registers > [0,N)? Right. > Also, could you provide me some pointers to the APIs that allow > dynamically reserving registers? TRI::getReservedRegs.

Does anyone know if there is a way to reserve a register set not to be used by a compiler? For example there are 64 available registers and the compiler can use only registers 0-31 and 40-45, and the others should be left alone. I know that the simplest solution is to simply change number registers in one of the .td files, but what I'm looking is an option to use at run time. I need this to

...his code is completely different on trunk. Specifically, the RegisterClassInfo class now caches this information. It does cache information between functions, but it should invalidate the cache when the set of reserved registers change: // Different reserved registers? BitVector RR = TRI->getReservedRegs(*MF); if (RR != Reserved) Update = true; Reserved = RR; // Invalidate cached information from previous function. if (Update) ++Tag; Please verify that it works, though. As you can see, the set of reserved registers doesn't normally change. /jakob

...he erroneous over-writing of a live preg.) Also, I'm confused about the code that gets a preg for a given vreg. Previously,you gave me code that takes into account the "allocation order" and the "reserved regs", including the following: BitVector reservedRegs = TRI->getReservedRegs(Fn); ArrayRef<uint16_t> rawOrder = trc->getRawAllocationOrder(Fn); ArrayRef<uint16_t>::iterator rItr = rawOrder.begin(); while (rItr != rawOrder.end()) { while (rItr != rawOrder.end() && reservedRegs.test(*rItr)) { ++rItr;...

While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets. I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable

...different on trunk. > > Specifically, the RegisterClassInfo class now caches this information. It does cache information between functions, but it should invalidate the cache when the set of reserved registers change: > > // Different reserved registers? > BitVector RR = TRI->getReservedRegs(*MF); > if (RR != Reserved) > Update = true; > Reserved = RR; > > // Invalidate cached information from previous function. > if (Update) > ++Tag; > > Please verify that it works, though. As you can see, the set of reserved registers doesn't normally chang...

...ask the differences between a "reserved" register and an >> "unallocable" register. In X86 backend, for example, the stack pointer >> register and instruction pointer are reserved but allocatable. In the >> Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, >> it says that a reserved register is one that *has particular uses and >> should be considered unavailable at all times. *If it is unavailable at >> all times, why not make such a reserved register unallocatable? Thanks! >> >> Regards, >> Lei Mou >> >...

...e just that: conventions on how to perfrom calls, I hope we don't have code in LLVM that changes which registers are reserved based on the calling convention. I assume they used a modified version of LLVM that also reserved those registers, at least I don't see any code in X86RegisterInfo::getReservedRegs() that would result in a heap or process pointer thing getting reserved. - Matthias

Hi Susan, Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg operand, taking the subregister index into account. That is what my examples have been doing manually. Using substPhysReg would allow you to tidy the Gcra code up slightly. - Lang. On Thu, Nov 15, 2012 at 11:21 AM, Lang

On Thu, Jul 19, 2012 at 4:04 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/19/12 2:52 PM, Xin Tong wrote: >> >> On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> >> wrote: >>> >>> On 7/19/12 1:23 PM, Jim Grosbach wrote: >>>> >>>> Not really, no. >>> >>> >>> If

Dear community, My company is interested in porting LLVM to OpenVMS. To do so, we need to look at extending the AMD64 calling convention to suit the existing calling conventions available on OpenVMS. We realize LLVM is a big and complex project and for some people who has not worked on it before, it's going to be a big and tough job that is going to take a lot of time. Still, the job has to

Thanks Jakob. I should have mentioned that earlier. :) When you see mismatched sizes on operands it's a fair bet that the subreg rewriting has gone wrong. I should have pulled that entirely out of the preg search loop in the previous example. Fixed version attached. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all I saw presentation http://www.softlab.ntua.gr/~gtsiour/files/erllvm_pres-20111107.pdf and I have couple question to the HiPE calling convention. I am trying to enable HiPE call for Rust compiler. That presentation mentioned that: Virtual registers with “special” use, pinned to hardware registers (unallocatable). VM Register AMD64 Register Native stack pointer %nsp Heap

On 7/19/12 2:52 PM, Xin Tong wrote: > On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> wrote: >> On 7/19/12 1:23 PM, Jim Grosbach wrote: >>> Not really, no. >> >> If you really, really, wanted to do it, you could: >> >> 1) Hack the code generator to not use that register. It might be as simple >> as modifying the

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

Hi, How can I reserve an ARM register for only a part of the code? Example: lets say I have 3 functions, A(), B() and C(). I want to prohibit compiler from using a register (lets say X9 in ARM 64) in function C() only. I think that by AArch64RegisterInfo::getReservedRegs function, a register can be reserved for the whole program. But, I need to reserve for only part of the code. Can I implement a custom #pragma to do it? Thanks and Best Nisal

...hey're using it wrong, or if there's any danger of clobbering the wrong registers, because we have that knowledge in the MC layer. Makes sense? > - We don't have a generic register reservation mechanism today. Well, TargetRegisterInfo::getAllocatableSet() enquires the targets for getReservedRegs() which could be set to take into account named register globals. Since they're module globals, this could be done once per compilation job, making it a lot simpler. > If you don't believe the last part... I didn't say it would be simple... ;) And I agree with you that we should...