search for: unallocatable

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...

> 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 into the doxygen comments of MachineRegisterInfo etc. And I also hope that people...

...). This can mean the the register is read multiple times. This optimization was added for the ARM64 zero register. Thanks, /jakob > On Feb 25, 2016, at 18:14, 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 into the doxygen comments of MachineRegisterInfo etc. And I also hope that people...

...read multiple times. This optimization was added for the ARM64 zero register. > > Thanks, > /jakob > > >> On Feb 25, 2016, at 18:14, 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 into the doxygen comments of MachineRegisterInfo etc. And I also hope that people...

...zation was added for the ARM64 zero register. >> >> Thanks, >> /jakob >> >> >>> On Feb 25, 2016, at 18:14, 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 into the doxygen comments of MachineRegisterInfo etc. And I also hope that people...

...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 scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120418/6218aac7/attachment.html>

...r 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. Reserved registers. 3. The rest: Unallocatable, unreserved registers. The set of reserved registers is not known to TableGen, and it can vary for different sub-targets, and even different functions. The res...

> On Feb 25, 2016, at 9:24 PM, Andrew Trick <atrick at apple.com> wrote: > > >> 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 into the doxygen comments of MachineRegisterInfo etc. And I also hope that people...

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

...ification, all registers behave like this. See [1] for a note on program counter/time stamp registers. == Implications == - We skip Liveness analysis because we know a reserved register is live anyway. - Register allocators cannot use a reserved registers: It is never free and therefore considered unallocatable. - Scheduling has to consider the implicit use on calls - No special considerations necessary for copy propagation - Writes to a reserved register are not dead code, because the value is always live out! == Examples == Assume r0 is a normal register r1 is a reserved register: - We can remove the...

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 but reserved *(in X86RegisterInfo.cpp). Since these registers also have special usage, why...

...program counter/time stamp registers. Hmm, I don’t see how pc can fit this rule. > > == Implications == > - We skip Liveness analysis because we know a reserved register is live anyway. > - Register allocators cannot use a reserved registers: It is never free and therefore considered unallocatable. > - Scheduling has to consider the implicit use on calls > - No special considerations necessary for copy propagation Ditto for pc. > - Writes to a reserved register are not dead code, because the value is always live out! > > == Examples == > Assume r0 is a normal register r1...

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

...by their nature can't be in SSA form. Lang and I have been trying to come up with some rules, but we haven't found the right set yet. So far, we are enforcing: - Allocatable registers cannot be live across basic blocks, except on entry to ABI blocks (the entry block and landing pads). - Unallocatable registers may be live across basic blocks, but you can't use aliases. (For example, you can't define CTR8 in one block and read CTR in another). - Reserved registers can do whatever you want, but defs are treated as having side effects, blocking certain optimizations like dead code elimina...

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, > >

Hi guys, There seems to have been some discussion about this before (http://mail.opensolaris.org/pipermail/zfs-discuss/2006-September/013050.html) but I don''t *quite* understand why the roundup is necessary. Using Bill''s notation, if there isn''t a roundup (writing 4k fs blocks to a 4 device RAID-Z) wouldn''t you get something like this: Disk 0 1 2

...g to take the next step now and separate out the blobs that I'm emitted as part of pseudos. I want to have individual instructions, even if they are part of bundles. That also makes it easier on the direct object emitter. MOdelling this T8 register (the source of most of the pseudos) as an unallocatable condition code regiter it probably the right thing to do. I will think about that. This particular register can be copied to normal mips16 registers but I try and avoid that and instead use it as is using special instructions that implicitly use T8. On 02/16/2013 11:49 PM, Cameron Zwarich wrote:...

...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 pointer %r15 Process pointer %rbp Reading that I am under impression that both r15 and rbp should not be used in functions marked using "HiPE" calling convention. That's it looks like r15 and...

...well for your delay slots. Bundles will force instructions to stay together in sequence, and there is really no other way to do this with arbitrary instructions. If you have a compare instruction that generates a flag and a branch instruction that uses it, you want to model this dependency with an unallocatable physical register, e.g. the CPSR on ARM: // Condition code registers. def CCR : RegisterClass<"ARM", [i32], 32, (add CPSR)> { let CopyCost = -1; // Don't allow copying of status registers. let isAllocatable = 0; } This will require you to mark defs and uses (and kills), b...

...ese registers don't get a LiveInterval, and are skipped here: // Reserved registers are OK. if (MO.isUndef() || !lis.hasInterval(MO.getReg())) continue; Reserved registers with defs get LiveIntervals, and are value-checked just like virtual registers. Also note that unreserved, unallocatable registers exist. For example the ARM %cpsr status register. /jakob