similar to: [LLVMdev] LiveIntervals for FunctionPass

It's done at the MachineFunctionPass level as far as I can tell ( http://llvm.org/doxygen/classllvm_1_1LiveIntervals.html). I'd like something at the FunctionPass level. On Tue, Aug 19, 2008 at 6:11 PM, Evan Cheng <evan.cheng at apple.com> wrote: > I am not sure what you mean. Live interval analysis is done at the > function level. > > Evan > > On Aug 19, 2008,

I am not sure what you mean. Live interval analysis is done at the function level. Evan On Aug 19, 2008, at 1:26 AM, Sean Soria wrote: > Is there an equivalent to LiveIntervals that works at the Function > level? If not, is there anything that makes it difficult to > implement compared to the MachineFunction version? > > Sean >

Ok. If it's at llvm ir level, it's very simple since everything is in SSA form. What are you trying to achieve though? Evan On Aug 19, 2008, at 6:51 PM, Sean Soria wrote: > It's done at the MachineFunctionPass level as far as I can tell (http://llvm.org/doxygen/classllvm_1_1LiveIntervals.html > ). I'd like something at the FunctionPass level. > > On Tue, Aug 19,

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

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce

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 Tuesday 04 May 2010 05:45:36 Josef Eisl wrote: > >> - As far as I understand it, register allocators are implemented as > >> MachineFunctionPasses. Does a MachineFunction object contain all > >> information needed for a (classic) allocator? > > > > It has the instructions, operands and dependencies among them. There's > > a

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

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

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,

David Greene wrote: > On Saturday 01 May 2010 08:34:50 Josef Eisl wrote: >> Hello, >> >> I want learn more about register allocation and do some analysis for a >> current research project. After reading some papers (eg. Chaitin, >> Briggs) I think its time to get my hands dirty :). > > Welcome! > >> First I plan to (re)implement some of the classic

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

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 , Benjamin Kramer wrote: >>> Do you want to take over this effort or should I poke more at it? >> >> Since you've already started, it's easier if you poke more at

Here are some recent stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Misc stuff: I ran into an

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-15 16:39 , Benjamin Kramer wrote: >> Do you want to take over this effort or should I poke more at it? > > Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. OK, will do. Jakob any comments on the

Chris Lattner wrote: > > Thanks, this works! I don't yet understand why spill code is needed there > > at all, but I'll return to that when I have branches working correctly. > > I'm not sure either. Can you send the code before and after register > allocation? Attached. > You might also try -regalloc=linearscan, as the default > allocator is, uhhh,

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*

On Wed, 9 Jun 2004, Vladimir Prus wrote: > Chris Lattner wrote: > > > Thanks, this works! I don't yet understand why spill code is needed there > > > at all, but I'll return to that when I have branches working correctly. > > > > I'm not sure either. Can you send the code before and after register > > allocation? > > Attached. Okay, yeah

Hi, I'm trying to use the VLIWPacketizerList to schedule instructions for the R600 target, and I'm running into this assertion failure: ScheduleDAGInstrs.cpp:558: Cannot schedule terminators or labels! I think I might not be using the VLIWPacketizerList class correctly. I've attached my code to this email. Can anyone spot what I'm doing wrong? Also, I had to add a LiveIntervals