similar to: [LLVMdev] Finding live registers at a specific point in a MachineFunction and spilling them

On Sep 3, 2013, at 17:21 , Manuel Jacob <me at manueljacob.de> wrote: > The problem is to safe registers that contain gc pointers to the stack > before a call and reload them after the call. Is there an Analysis Pass > that computes information about which registers are live during a > specific instruction? I looked at LiveIntervals and LiveVariables, but > they seem to be for

I though LiveVariables may be invalidated by LiveIntervals, but it's declared not: void LiveIntervals::getAnalysisUsage(AnalysisUsage &AU) const { AU.addPreserved<LiveVariables>(); AU.addRequired<LiveVariables>(); ... LiveInterval may coalesce virtual registers and remove identity moves instructions: bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) {

LiveVariables gives you something like liveness analysis: where each variable is alive, that is, across each basic blocks, where it is defined, and where it is killed. LiveIntervals gives you a linear representation of the variables as a set of intervals. Yes, it handle holes in the live ranges. There is a very nice description of these analysis and related data structures here:

Fernando Magno Quintao Pereira wrote: > LiveVariables gives you something like liveness analysis: where each > variable is alive, that is, across each basic blocks, where it is defined, > and where it is killed. If I read this correctly, it means that at each instruction there's a list of live variables? I'm trying to figure out how to get at this information to build the

One of my pass requires LiveIntervals to build the interference graph, because LiveVariables do not provide an interface to iterate through all viritual registers. But LiveIntervalAnalysis.h is not in "include/llvm/CodeGen", so I have to either include it by: #include "../../llvm/lib/CodeGen/LiveIntervalAnalysis.h" or point my project include path to

On Mar 27, 2007, at 3:25 PM, Evan Cheng wrote: > > On Mar 25, 2007, at 7:12 AM, Christopher Lamb wrote: > >> While beginning to add vector registers to a back end I came >> across the following problem: as soon as I define two sets of >> registers that have a many-to-one mapping the live interval pass >> appears to double-kill the mapped-onto register. I

Hello to all LLVM developers. I'm developing a register allocator using LLVM, my allocator has a local search phase: given a solution (assignment of virtual registers to physical registers or memory) generated in the first phase of the algorithm, some movements are applied to this solution in order to find a better solution. To apply such movements, I need to unassign a virtual register from

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > One of my pass requires LiveIntervals to build the interference graph, Ok. > because LiveVariables do not provide an interface to iterate through > all viritual registers. Ok, you could add a method to LiveVariables that returns VirtRegInfo.size(). The virtual registers are defined by the range: [MRegisterInfo::FirstVirtualRegister,

On Apr 3, 2007, at 3:45 PM, Christopher Lamb wrote: > >> Can you dump out the machine basic block? It should have an >> implicit use of V4R0 at first ORI but it should not be marked kill. >> If it is marked kill, then you need to walk LiveVariables.cpp to >> find out why. > > Here is the beginning of the BB dump. > > entry (0x8503c80, LLVM BB @0x8501af0,

On 20/09/05, Chris Lattner <sabre at nondot.org> wrote: > > because LiveVariables do not provide an interface to iterate through > > all viritual registers. > > Ok, you could add a method to LiveVariables that returns > VirtRegInfo.size(). The virtual registers are defined by the range: > [MRegisterInfo::FirstVirtualRegister, >

Hey all, I'm attempting to rewrite something that the AVR backend used to support (through an extremely dirty hack that was reverted before the upstreaming of the target). The removal of the hack can be seen on GitHub https://github.com/avr-llvm/llvm/pull/226/files On the AVR architecture, the stack pointer is not in a standard register, but rather it is a special register which can only

Toward a better register allocator, I'm attempting to understand the dataflow information available to the allocator. What's the difference between LiveInterval information and LiveVariable information? If a LiveInterval is based on a linear ordering of the machine instructions, isn't it rather conservative in nature? Let's say I have a typical diamond CFG: A

On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all the intervals rerun LiveIntervals::computeVirtRegs after all the CFG transforms are complete? Yes, I should think so. /jakob -------------- next part -------------- An HTML attachment was

- Please do not add any more uses of the LiveVariables pass! It is deprecated and only kept around for one last pass that isn't converted. All new code should use LiveIntervalAnalysis! - Kill flags are optional: If they are present they must be correct, but it is legal to have a value die without having a kill flag on the operand. So often a simple fix is to clear out the kill flags from

On 4/3/07, David Greene <greened at obbligato.org> wrote: > > Toward a better register allocator, I'm attempting to understand > the dataflow information available to the allocator. > > What's the difference between LiveInterval information and LiveVariable > information? If a LiveInterval is based on a linear ordering of > the machine instructions, isn't it

Does anybody have any tips for generating spills/reloads for large non-vector registers? I'm working on a back end for a DSP architecture that has accumulator registers that are too large to be spilled or reloaded with a single instruction. All of their bits can be accessed in word-size chunks via three sub-registers (low, high, and ext). So loading or storing one requires three instructions:

On Jan 4, 2014, at 4:38 AM, Haishan <hndxvon at 163.com> wrote: > At 2014-01-04 06:11:38,"Jakob Stoklund Olesen" <stoklund at 2pi.dk> wrote: > > On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > >> He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all

[Splitting this out from the original thread to reduce noise in it] On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,

Hi, I wonder if there is a way in LLVM to disable spilling a register-class while still enabling the super-registers of this register-class to be spilled. If not, how can we implement spilling for sub-registers when stack load/stores can only operate on the super registers? Is there a way even if it is suboptimal? Thanks, Ahmed

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even