similar to: [LLVMdev] Conceptual difference between "Unallocatable" and "Reserved" registers.

On Apr 17, 2012, at 9:09 PM, Lei Mou wrote: > 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

Hi Aries, Thank you for your reply. I understand that the registers you mentioned should not be used at will. The problem I don't understand is why not make these registers *unallocatable*. Since in X86RegisterInfo.td, only floating point stack registers ST0 to ST7 and status flag registers are defined as not allocatable, while special registers such as ESP/EIP/EBP are defined as *allocatable

On Thu, 7 Jun 2012 22:14:00 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > > > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > > Predecessors according to CFG: BB#0 BB#1 > > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, > >

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

On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote: > For example, sometimes LiveIntervals asserts with: > register: > %CTR8 > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > void llvm::LiveInterval > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > llvm::MachineOperand&,

On 02/25/2016 06:14 PM, Matthias Braun via llvm-dev wrote: > 1) The value read from a reserved register cannot be predicted. Reading a reserved register twice may each time produce a different result. This seems broken to me that treating another copy should be assumed to produce a different result. This seems like it should be optimized, and have a special volatile_copy instruction for the

On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote: > 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

Let's try this again after some longer offline discussions: = Reserved Registers = The primary use of reserved registers is to hold values required by runtime conventions. Typical examples are the stack pointer, frame pointer maybe TLS base address, GOT address ... Zero registers and program counters are an odd special case for which we may be able to provide looser rules. == Rules == 1)

> On Feb 25, 2016, at 6:14 PM, Matthias Braun <mbraun at apple.com> wrote: > > Lately I have had a few discussions of what it means for a register to be unallocatable or reserved. As this comes up every now and again and I often struggled answering such questions I decided to write down some definite rules and codify the current usage and assumptions. I plan to put the rules below

Hi Matthias, This pretty much matches my memory. I think that the rules are a bit ad hoc and not followed to the letter everywhere. It would be good to codify something concrete. I thought that I added some way of distinguishing between constant registers and other reserved registers but I can’t find it now. We do some register coalescing that is not consistent with your rules here: If a virtual

Lately I have had a few discussions of what it means for a register to be unallocatable or reserved. As this comes up every now and again and I often struggled answering such questions I decided to write down some definite rules and codify the current usage and assumptions. I plan to put the rules below into the doxygen comments of MachineRegisterInfo etc. And I also hope that people will correct

Hi Matthias, Thanks for doing this. Each time we talk about it, it takes us 10 min to rebuild those rules form our recollection, so definitely useful to write them down. I am in agreement with what you wrote down. I just think we need additional rules for the constant registers like Jakob mentioned: - Their value is constant (i.e., copy propagation is fine, unlike regular reserved registers). -

There is MachineRegisterInfo::isConstantPhysReg(), in the current implementation this just returns true if it cannot find any def operand for the register (or on of its aliases). I think we also write to zero registers at times and then this function would return false... For this to work reliably targets would need to provide the constant information explicitely. For the "writing to them

I'm working on some enhancements to rematerialization that I hope to contribute. It's mostly working but I am running into one problem. It boils down to having spilled a register used by the remat candidate. I thought this is what getReMatImplicitUse is supposed to handle but it looks inconsistent to me. The comment says this: /// getReMatImplicitUse - If the remat definition MI has

On Nov 16, 2011, at 9:15 AM, David Greene wrote: > I'm working on some enhancements to rematerialization that I hope to > contribute. What do you have in mind? > It's mostly working but I am running into one problem. It > boils down to having spilled a register used by the remat candidate. > > I thought this is what getReMatImplicitUse is supposed to handle but >

You are trying to do a few different things here, and a uniform solution may not work for all of them. For a fixed instruction sequence, e.g. a special kind of move-and-branch sequence used for tail calls, you probably want a pseudo. If you are trying to combine arbitrary instructions together, e.g. Thumb IT blocks, you probably want to use bundles, even if the sequences are a fixed length. I

On 2/26/2016 7:09 PM, Quentin Colombet via llvm-dev wrote: > To summarize my thoughts, I believe reserved registers were introduced > to fill the gap of want we don’t model. E.g., for pc for instance, each > instruction should implicitly define it, then the actual use are > predictable. Since we don’t do that, we need to conservatively assume > that the value of a reserved register

> On Feb 26, 2016, at 1:54 PM, Matthias Braun <mbraun at apple.com> wrote: > > Let's try this again after some longer offline discussions: > > = Reserved Registers = > The primary use of reserved registers is to hold values required by runtime conventions. Typical examples are the stack pointer, frame pointer maybe TLS base address, GOT address ... > Zero registers

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 28 March 2014 10:17, Chandler Carruth <chandlerc at google.com> wrote: > This has been the long standing historical objection to the feature. It is a > *really* invasive change to the register allocator to plumb this kind of > register reservation through it. Do you mean only the reserved part or the general named register idea? About reserving registers, we already have the