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

> 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

> 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

> 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

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

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)

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

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

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 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 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 Sep 29, 2017, at 4:12 AM, denisgolovan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

Hi, How to unlist list column value and add column into data frame. Data frame ID ContractDe PassengersDe TrainnerDe 1 list(ConID=c("Zx","78yu"),ConRes = c("98","Tut")) list(PassID

On Fri, 8 Jun 2012 08:49:32 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > 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 > >

Hello, Sam I used non-arm backend, and I used a target which likes mips has both big and little endianness. And I have ported llvm-gcc to this platform along with llvm backend. The issue is about IR endianness and how backend deal with the data and instructions in different endian, since I discovered 2 different IR generates the same asm code by llc for different endian target. > Message: 27

Hi Lei, Le 31/05/2012 03:44, Lei Mou a écrit : > Problem solved by returning the second result of the ATOMIC_LOAD_OR node... You got the chain instead of the loaded value. IMHO, a better solution would have been to add a Pat<> rule to match truncstores and expand them into target store/load/and/or. Pat : <(truncstore16 GPR:$val, MEM:$mem), (store MEM:$mem, (or

On Mon, Apr 16, 2012 at 3:48 AM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi all, > > I'm learning the PTX backend and confused by the following problem. In the > constructor of PTXFrameLowering, StackAlignment and LocalAreaOffset are > assigned 2 and -2, respectively. Since PTX has neither stack frame nor > stack pointer, why StackAlignment and LocalAreaOffset are

Problem solved by returning the second result of the ATOMIC_LOAD_OR node... On Wed, May 30, 2012 at 9:38 PM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi, > > Our target only has native support for i32 and f32 types. For data > types smaller than these, I have to custom lowering truncating store > using two atomic load instruction (which have the same semantics as >