similar to: [LLVMdev] Basic block liveouts

Because I feel bad for giving a non-answer: An easy way to find if a virtual register is alive after the basic block is to While iterating over the virtual registers - Check to see if the virtual register's "next" value exists outside of the basic block. for instance: std::vector<unsigned> findLiveOut( MachineBasicBlock * mbb ) { std::vector<unsigned> liveout; for(

They cannot be found like the live in values because different values may be live out. For instance the psudocode may look like: BB0: vreg1 = rand() if( vreg1 > .5 ) goto BB1; else goto BB2; BB1: vreg 2 = rand(); EAX = copy vreg2; Return BB2: vreg 3 = rand() * rand()' EAX = copy vreg3; Return On Fri, Nov 5, 2010 at 7:41 AM, s Last namerc <srcsrc84 at yahoo.com>

Thanks for the information. I still don't know how do I partition registers into different classes from the virtual registers? For instance, I have the function who which iterates over the instructions, but I don't know how to write the function which returns the different register class. void RAOptimal::Gather(MachineFunction &Fn) { // Gather just iterates over the blocks,

On Sat, Aug 28, 2010 at 16:20:42 -0400, Jeff Kunkel wrote: > What I need to know is how to access the machine register classes. Also, I > need to know which virtual register is to be mapped into each specific > register class. I assume there is type information on the registers. I need > to know how to access it. MachineRegisterInfo::getRegClass will give you the TargetRegisterClass

So I have a good understanding of what and how I want to do in the abstract sense. I am starting to gain a feel for the code base, and I see that I may have a allocator up and running much faster than I once thought thanks to the easy interfaces. What I need to know is how to access the machine register classes. Also, I need to know which virtual register is to be mapped into each specific

Here is an updated patch for shrink wrapping with: - spills/restores done with stack slot stores/loads - stack adjustment removed - refactoring (but still in need of more) - spill/restore insertion code unified with spill/restore placement code Documentation available here<http://wiki.github.com/jdmdj/llvm-work/shrink-wrapping-work> illustrates shrink wrapping with loops and discusses a

Hi John, It looks pretty good. Thanks for working on this. Some comments: 1. Some of the functions that you introduced, e.g. stringifyCSRegSet probably ought to be "static" and ifdef'ed out when NDEBUG is defined. 2. + // DEBUG + if (! MBB->empty() && ! CSRUsed[MBB].intersects(restore)) { + MachineInstr* MI = BeforeI; + DOUT <<

On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote: > > On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > > Obviously, all of this applies only when spills are done with push/pop, > which is the case on x86. I used this issue to start looking at generalizing > how spills and restores are handled, before looking too closely at other > targets, and

Chris Lattner wrote: > On Thu, 12 Apr 2007, David Greene wrote: >> As I work toward improving LLVM register allocation, I've >> come across the need to do some refactoring. > > cool. :) One request: Evan is currently out on vacation until Monday. > This is an area that he is very interested in and will want to chime in > on. Please don't start anything

Hi Evan, Thanks very much for the review, I am implementing your suggestions today and will have the next patch together this weekend. A few questions/comments: On Thu, Mar 12, 2009 at 10:05 AM, Evan Cheng <echeng at apple.com> wrote: > > 1. Some of the functions that you introduced, e.g. stringifyCSRegSet > probably ought to be "static" and ifdef'ed out when NDEBUG

On Thu, 12 Apr 2007, David Greene wrote: > As I work toward improving LLVM register allocation, I've > come across the need to do some refactoring. cool. :) One request: Evan is currently out on vacation until Monday. This is an area that he is very interested in and will want to chime in on. Please don't start anything drastic until he gets back :). > Specifically, I would

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

Hi all, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

Thank you. Is it possible to determine the liveout of the operands (see example bellow) ? %5 = add i32 %4, %3 For '%5': i can simply use " i->isUsedOutsideOfBlock() " For '%3' and '%4' : this is the question ... >From your answer, is it possible to determine *which* value is liveout ( in binary instruction)? On Sat, May 30, 2009 at 2:57 AM,

Hi, How can i know, if a value have uses outside of the current basic block (liveout), without iterating through all the basic block ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090530/71681bc2/attachment.html>

I believe Dan has added a pass to compute livein / liveout values. Evan Sent from my iPhone On May 30, 2009, at 5:03 AM, Rotem Varon <varonrotem at gmail.com> wrote: > Thank you. > > Is it possible to determine the liveout of the operands (see example > bellow) ? > > %5 = add i32 %4, %3 > > For '%5': i can simply use "

The pass you're referring to is in include/llvm/Analysis/LiveValues.h and lib/Analysis/LiveValues.cpp. It computes conservative approximations for specific liveness queries, rather than full livein/liveout information. It's intended to be used as a heuristic. Dan On May 30, 2009, at 3:51 PM, Evan Cheng wrote: > I believe Dan has added a pass to compute livein / liveout values. >

On May 29, 2009, at 11:37 PM, Rotem Varon wrote: > How can i know, if a value have uses outside of the current basic > block (liveout), without iterating through all the basic block ? If the value is created within the basic block in question, and the block doesn't loop to itself, then you can just iterate through the uses and note if the use is an instruction in a different

On May 30, 2009, at 5:03 AM, Rotem Varon wrote: > Is it possible to determine the liveout of the operands (see example > bellow) ? > > %5 = add i32 %4, %3 > > For '%5': i can simply use " i->isUsedOutsideOfBlock() " > For '%3' and '%4' : this is the question ... By definition, operands are live out if they're used in any

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using