search for: spillplacement

MSVC complains of truncating a double to a float. Let's just give it a float. -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -------------- next part

...abilities? > Agreed. An important consideration here is WPO vs. LTO vs. TU-at-a-time call graphs. > FWIW, the greedy register allocator’s live range splitting algorithm is > designed to consume profile information so it can push spill code into cold > blocks. The primary interface is SpillPlacement::getBlockFrequency() which > currently returns an estimate based on loop depth only. > It doesn't use MachineBlockFrequency? If it does, it will get a lot more than loop depth: __builtin_expect, cold function attribute, and static branch heuristics. If it doesn't it should, and then...

...seems like we might need a way of representing call graph profiling in addition to the existing branch probabilities? FWIW, the greedy register allocator’s live range splitting algorithm is designed to consume profile information so it can push spill code into cold blocks. The primary interface is SpillPlacement::getBlockFrequency() which currently returns an estimate based on loop depth only. /jakob

...named, it returns a fixpoint number. I think you should scale it to be relative to the entry block frequency. +LiveIntervals::getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { + return (isDef + isUse) * freq.getFrequency(); } This computation can overflow. @@ -178,9 +180,10 @@ bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) { // Compute total ingoing and outgoing block frequencies for all bundles. BlockFrequency.resize(mf.getNumBlockIDs()); + MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); for (MachineFunction::iterator I...

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

...ing RegAllocGreedy.cpp for Release+Asserts build /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h: In member function ‘void<unnamed>::RAGreedy::calcLiveBlockInfo(llvm::LiveInterval&)’: /Users/filcab/dev/stuff/llvm/llvm/include/llvm/ADT/SmallVector.h:325: warning: ‘BC.llvm::SpillPlacement::BlockConstraint::Exit’ is used uninitialized in this function ---------------------------- ^^ The error repeats several times. It seems the error occurs when push_back copies the received object, which is a struct: struct BlockConstraint { unsigned Number; ///< Basic block number (from MBB::g...

...abilities? > > Agreed. An important consideration here is WPO vs. LTO vs. TU-at-a-time call graphs. > > FWIW, the greedy register allocator’s live range splitting algorithm is designed to consume profile information so it can push spill code into cold blocks. The primary interface is SpillPlacement::getBlockFrequency() which currently returns an estimate based on loop depth only. > > It doesn't use MachineBlockFrequency? If it does, it will get a lot more than loop depth: __builtin_expect, cold function attribute, and static branch heuristics. If it doesn't it should, and then...

I'm working on generating code for a machine that has a register set kind of like the 68000. For those who don't recall, the 68K has 8 Data registers that can be used for ordinary integer instructions like add, subtract, multiply, shift, etc., and 8 Address registers that can be use for integer addition and a few other things, especially base registers for addressing modes. The Data

...getSpillWeight(bool isDef, bool isUse, BlockFrequency freq) { > + return (isDef + isUse) * freq.getFrequency(); > } > > This computation can overflow. Yep, I went down the easy route and converted it to floating point arithmetic. Is that OK here? > > @@ -178,9 +180,10 @@ bool SpillPlacement::runOnMachineFunction(MachineFunction &mf) { > > // Compute total ingoing and outgoing block frequencies for all bundles. > BlockFrequency.resize(mf.getNumBlockIDs()); > + MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); > for (Machine...

On Wed, Jun 12, 2013 at 3:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > It predates the block frequency interface. It just needs to be hooked up, > patches welcome. It would also be nice to remove the floating point > computations from the spill placement code. Cool, if Diego doesn't beat me to it, I may send you a patch as that seems easy and obviously

I have started looking at the state of PGO (Profile Guided Optimization) in LLVM.**I want to discuss my high-level plan and make sure I'm not missing anything interesting out. I appreciate any feedback on this, pointers to existing work, patches and anything related to PGO in LLVM. I will be keeping changes to this plan in this web document

...g model, and that means we can get away with using a very fast, very stupid algorithm (stolen from Hopfield networks) that simply converges on a nearby local minimum. We don’t actually need to use simulated annealing or other fancy optimization algorithms. Stupid Ising model optimizer: lib/CodeGen/SpillPlacement.cpp More on D-Wave: http://arstechnica.com/science/2013/08/d-waves-black-box-starts-to-open-up/ More on Ising models and Hopfield networks: http://www.inference.phy.cam.ac.uk/mackay/itila/ Thanks, /jakob

enableAdvancedRASplitCost() does the same thing as ConsiderLocalIntervalCost, but as a subtarget option instead of a command-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John

...for Release+Asserts build llvm[2]: Compiling ShadowStackGCLowering.cpp for Release+Asserts build llvm[2]: Compiling ShrinkWrap.cpp for Release+Asserts build llvm[2]: Compiling SjLjEHPrepare.cpp for Release+Asserts build llvm[2]: Compiling SlotIndexes.cpp for Release+Asserts build llvm[2]: Compiling SpillPlacement.cpp for Release+Asserts build llvm[2]: Compiling SplitKit.cpp for Release+Asserts build llvm[2]: Compiling StackColoring.cpp for Release+Asserts build llvm[2]: Compiling StackMapLivenessAnalysis.cpp for Release+Asserts build llvm[2]: Compiling StackMaps.cpp for Release+Asserts build llvm[2]: Compil...