search for: calcspillweights

...t the same assert : "Attempting to spill already spilled value." This is triggered because in RegAllocPBQP::mapPBQPToRegAlloc, a vreg node is either : - a physical register (problem.isPRegOption(vreg, alloc)), - or a spill (problem.isSpillOption(vreg, alloc)) The problem is that pass CalcSpillWeights can 'hint' that it is a poor idea to spill this specific register with : CalcSpillWeights.cpp / VirtRegAuxInfo::CalculateWeightAndHint : // Mark li as unspillable if all live ranges are tiny. if (li.isZeroLength(LIS.getSlotIndexes())) { li.markNotSpillable(); ... This hint mak...

...to spill already spilled > value." > > This is triggered because in RegAllocPBQP::mapPBQPToRegAlloc, a vreg node is > either : >  - a physical register (problem.isPRegOption(vreg, alloc)), >  - or a spill (problem.isSpillOption(vreg, alloc)) > > The problem is that pass CalcSpillWeights can 'hint' that it is a poor > idea to spill this specific register with : > > CalcSpillWeights.cpp / VirtRegAuxInfo::CalculateWeightAndHint : >  // Mark li as unspillable if all live ranges are tiny. >  if (li.isZeroLength(LIS.getSlotIndexes())) { >    li.markNotSpillable...

Hi Arnaud, Thanks for attaching those files. I'll take a look at them. Commit r153483 adds an option to the PBQP allocator, "-pbqp-dump-graphs", to dump the PBQP graph for each round of each function in a compilation unit. The generated files are named "<module id>.<function>.<round>.pbqpgraph", and contain a simple text representation of the PBQP graph.

Hi Lang, > From memory your target is not public, so I won't be able to reproduce > the crash myself. Is that correct? Correct. > If that's the case, I could add functionality to dump the PBQP graphs > during allocation. I think they should give me enough information to > debug the issue. Would you be able to share the PBQP graphs? I can share the pbqp graph if you send

Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator. Update the documentation style while there. I also intend to take VirtRegAuxInfo out of line in a later patch as this is really a helper class for spill weight (re) com...

Hi Arnaud, Apologies for the delayed reply. Thank you for the excellent test case - it exposed a subtle bug in the colorability heuristic. This has been fixed in r153958. In case you are curious, the bug was as follows: the PBQP solver applies applies a simplification step to each matrix. When all elements of a matrix row or column are equal, the value for those elements is "pushed

Hi Lang, The assert is not triggered any longer on my testcases :) I however still get my wrong allocation in some non trivial cases : the pairing constraint is not fulfilled. I have tried to modify the 'ensure pairable' pass (the pass undoing some of the coalescer's work) to always insert register copies for instructions with the pairable constraint, instead of being smart and

Hi Lang, I have reduced the testcase as much as possible. The log of the run and the dumped graphes are attached. Cheers, -- Arnaud de Grandmaison On Tuesday, March 27, 2012 01:20:35 Lang Hames wrote: > Hi Arnaud, > > Thanks for attaching those files. I'll take a look at them. > > Commit r153483 adds an option to the PBQP allocator, > "-pbqp-dump-graphs", to

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of

...ll this register for no reason at all in between these instructions. The CopyCost attribute would help me, if the register allocators would factor it in with the spillWeight calculation. I suppose this would be fairly simple to implement, given that all the register allocators except -fast use the CalcSpillWeights class, where it could be included. Would this make sense to you as a patch? Maybe CopyCost and SpillCost should be held separate, I don't know, but in this case a new attribute could be introduced. Jonas -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent:...

On Nov 8, 2013, at 7:40 AM, Arnaud Allard de Grandmaison <arnaud.adegm at gmail.com> wrote: > Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator. > > Update the documentation style while there. > > I also intend to take VirtRegAuxInfo out of line in a later patch as this is really a helper class for s...

...Nov 8, 2013, at 7:40 AM, Arnaud Allard de Grandmaison < > arnaud.adegm at gmail.com> wrote: > > > Based on discussions with Lang Hames and Jakob Stoklund Olesen at the > hacker's lab, and in the light of upcoming work on the PBQP register > allocator, it was though that CalcSpillWeights does not need to be a pass. > This change will enable to customize / tune the spill weight computation > depending on the allocator. > > > > Update the documentation style while there. > > > > I also intend to take VirtRegAuxInfo out of line in a later patch as > th...

...in, Sorry for the delay, I've been bogged down with other things today. On 14 July 2015 at 18:48, Quentin Colombet <qcolombet at apple.com> wrote: >> >> * A rematerializable interval once split is no longer rematerializable * >> >> The isRematerializable check in CalcSpillWeights.cpp uses the target >> instruction info to check that the machine instruction for the live >> interval definition is trivially rematerializable. In the case of >> interval A above, the definition is a load from the constant-pool. >> This is trivially rematerializable and th...

...his -localstackalloc -dead-mi-elimination -machinedomtree -machine-loops -machinelicm -machine-cse -machine-sink -peephole-opts -unreachable-mbb-elimination -livevars -phi-node-elimination -twoaddressinstruction -processimpdefs -slotindexes -liveintervals -livedebugvars -simple-register-coalescing -calcspillweights -livestacks -virtregmap -edge-bundles -spill-code-placement -stack-slot-coloring -machinelicm -edge-bundles -prologepilog -branch-folder -tailduplication -machine-cp -postrapseudos -machinedomtree -machine-loops -post-RA-sched -gc-analysis -machine-block-freq -block-placement2 -machinedomtree -mach...

Hi Lang, Thanks a lot for taking time to look into this. I will test the fix soon and let you know the results. Cheers, -- Arnaud de Grandmaison On Tuesday, April 03, 2012 17:30:33 Lang Hames wrote: > Hi Arnaud, > > Apologies for the delayed reply. > > Thank you for the excellent test case - it exposed a subtle bug in the > colorability heuristic. This has been fixed in

...d-mi-elimination > -machinedomtree -machine-loops -machinelicm -machine-cse -machine-sink > -peephole-opts -unreachable-mbb-elimination -livevars > -phi-node-elimination -twoaddressinstruction -processimpdefs > -slotindexes -liveintervals -livedebugvars -simple-register-coalescing > -calcspillweights -livestacks -virtregmap -edge-bundles > -spill-code-placement -stack-slot-coloring -machinelicm -edge-bundles > -prologepilog -branch-folder -tailduplication -machine-cp > -postrapseudos -machinedomtree -machine-loops -post-RA-sched > -gc-analysis -machine-block-freq -block-placement2 -...

...VALF is not accepted as a float constant on Mac OS X 10.4.11 (Intel)? ./llvm/include/llvm/CodeGen/LiveInterval.h:569: error: floating constant exceeds range of 'float' ./llvm/include/llvm/CodeGen/LiveInterval.h:574: error: floating constant exceeds range of 'float' llvm/lib/CodeGen/CalcSpillWeights.cpp:111: error: floating constant exceeds range of 'float Best regards, --Edwin -------------- next part -------------- An embedded message was scrubbed... From: James Brown <jlbrown at bordo.com.au> Subject: [Clamav-users] Compile error: floating constant exceeds range of 'float'...

I understand the mechanics. I don't know why a lesser weight is better than a greater weight. On Thu, Oct 28, 2010 at 7:22 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > >> I was studying the basic register allocator, and I am wondering why >> "LessSpillWeightPriority" priority was used over the

Let me rephrase my question. The live intervals have a weight associated with them. What does this weight exactly represent? Thanks Jeff Kunkel On Thu, Oct 28, 2010 at 7:41 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > I understand the mechanics. I don't know why a lesser weight is better > than a greater weight. > > > On Thu, Oct 28, 2010 at 7:22 PM, Jakob Stoklund

On 2012 2 2, at 08:40, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: > I was able to get rid of the 'moves' by setting the copycost to -1. > For getting rid of the spills, I was forced to introduce custom nodes, that pass the CC register > through 'glue'. > > Having a property to register classes that identifies a 'glue-like' behavior