search for: rematerializable

Hi Quentin, 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 >&gt...

...l attached). I have spent some time going through the register allocator to understand what is happening. I have also experimented with some small changes to try and improve the allocation. Unfortunately, the full report is fairly long and detailed. However, in short, I found that not splitting rematerializable live-ranges lead to significantly better register allocation, and an overall performance improvement of 3%. *** The Problem Compile the attached testcase as follows: llc -mcpu=btver2 test.ll Examining the assembly in test.s we can see a constant is being loaded into %xmm8 (second instruction in...

I have encountered a rather odd situation with Greedy where it will end up spilling a register that was populated with a zero (with a trivially rematerializable load-immediate instruction). In fact, it spills 3 such values (LICM moves stuff out of a loop, register coalescer replaces copies with load-immediates and then Greedy spills them). I personally can't think of a situation where a spill (with a reload later presumably) is better than simply rema...

...en. > > > On Feb 20, 2019, at 4:12 PM, Nemanja Ivanovic via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I have encountered a rather odd situation with Greedy where it will end > up spilling a register that was populated with a zero (with a trivially > rematerializable load-immediate instruction). > > In fact, it spills 3 such values (LICM moves stuff out of a loop, > register coalescer replaces copies with load-immediates and then Greedy > spills them). > > > > I personally can't think of a situation where a spill (with a reload >...

...0, 2019, at 4:12 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > I have encountered a rather odd situation with Greedy where it will end up spilling a register that was populated with a zero (with a trivially rematerializable load-immediate instruction). > > In fact, it spills 3 such values (LICM moves stuff out of a loop, register coalescer replaces copies with load-immediates and then Greedy spills them). > > > > I personally can't think of a situation where a spill (with a reload later presumab...

...f code where some stack offset address is calculated, but this address is then spilled to stack, and loaded from stack later. This does not make sense, it would be better to just recalculate the address later, ie rematerialize the original stack offset calculation. But marking some instruction rematerializable means all operands have to be always available? So I cannot make my add operation which is used for the stack offset calculations rematerializable because not all operands of all adds are always available? So how can I make llvm to try to rematerialize only those stack offset adds, but not a...

...:12 PM, Nemanja Ivanovic via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> > >>> > I have encountered a rather odd situation with Greedy where it will >>> end up spilling a register that was populated with a zero (with a trivially >>> rematerializable load-immediate instruction). >>> > In fact, it spills 3 such values (LICM moves stuff out of a loop, >>> register coalescer replaces copies with load-immediates and then Greedy >>> spills them). >>> > >>> > I personally can't think of a situ...

...;d like to do something better here. Could you expand on this a bit (or point me to past discussions/...)? This can be pretty important on architectures like Cell SPU. > For register allocation, LLVM currently has some simple hooks which > individual targets use to specify which loads are rematerializable. > See isReallyTriviallyReMaterializable. Currently this code is all > target-specific and doesn't use AliasAnalysis information, but I > think it could be reasonably generalized to use the new > MachineMemOperand information to be less target-dependent and to > make at least Ali...

...target is stable enough in LLVM, or may be I should just safely skip it during testing because it is not mature yet. Anyway, I report it here - may be it is of some interest. The crash happens in LiveIntervalsAnalysis, inside the spilling function. From what I observe, I'd say it is related to rematerializable intervals. The assertion says: /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end() && "Interval does not exist for register"' failed. I attach the BC file generated b...

On 9/24/2016 7:20 AM, Alex Bradbury wrote: > My concern is that all of the above adds yet more complexity to what > is already (in my view) a fairly difficult part of LLVM to understand. > The definition of MyRegisterClass is not so bad though, and perhaps it > doesn't matter how it works under the hood to the average backend > writer. I agree with the complexity, but I would

On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: > Our frontend can guarantee that loads from globals are > rematerializable and do not alias with any stores in any function in > the given module. We'd like the optimization passes (and ideally the > register allocator as well) to be able to use this fact. The globals > are not constant "forever" but are constant during the calling of any > given...

...ures like Cell SPU. I agree that it's an important capability. We're gradually working on adding the requisite pieces, and we welcome help :-). > > >> For register allocation, LLVM currently has some simple hooks which >> individual targets use to specify which loads are rematerializable. >> See isReallyTriviallyReMaterializable. Currently this code is all >> target-specific and doesn't use AliasAnalysis information, but I >> think it could be reasonably generalized to use the new >> MachineMemOperand information to be less target-dependent and to >&g...

...ister (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). I've tried to take the approach that's used by the X86 target, in which instructions _are_ trivially rematerializable even if they implicitly define the condition code (EFLAGS) but must take care not to clobber EFLAGS if it's live at the point where the instruction is remate...

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in...

...w-hanging maintenance tasks on the instruction definition tables for people interested. 4) If I'm reading the td files and I see things that are obviously wrong (for example, an instruction which loads but is not marked as such, or instructions which should be marked as (potentially) trivially rematerializable), should I just fix them and submit those fixes? Can I even write test cases for most of these? Clearly, what I consider "obviously wrong" will be informed by answers to #1 and #2 above. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm....

Hi, I have some constants that get loaded into a register, and then the register is copied to another register, and then used. I suspect this stems from PHI nodes lowering.I cannot avoid this right now, as the MI PHI's will only hold registers, and not constants. Therefore this gets complicated, having to handle the introduced copies from the Eliminate PHIs pass, while the IR is not on

...ister (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being rematerialized because it defines a physical register (TargetInstrInfo::isReallyTriviallyReMaterializableGeneric()). > > I've tried to take the approach that's used by the X86 target, in which instructions _are_ trivially rematerializable even if they implicitly define the condition code (EFLAGS) but must take care not to clobber EFLAGS if it's live at the point where the instruction...

Hi, 1. This instruction is not selected automatically by the instruction selector. The instruction combine / select stages insert registercopies, and they are expanded later on by the copyRegToReg() function provided by the MSP430InstrInfo to this MOV16rr. 2. ReMaterializable means there is no need to find a way to preserve the value in a register : the instruction can be just be reissued whenever the value is needed. This remove some pressure on register alloc, and avoid unnecessary spilling. 3. It says that beside doing an add, it also affects (implicitly) the condit...

...VM, or may be I > should just safely skip it during testing because it is not mature > yet. Anyway, I report it here - may be it is of some interest. > > The crash happens in LiveIntervalsAnalysis, inside the spilling > function. From what I observe, I'd say it is related to > rematerializable intervals. > > The assertion says: > /opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142: > llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int): > Assertion `I != r2iMap_.end() && "Interval does not exist for > register"' failed. >...

...reg1235 is spilled and at least one use is rematted. The remat def instruction is: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 88, Mem:LD(8,8) [tmp17731774 + 0] So this gets entered into ReMatDefs. %reg1461 is created for one of the spill intervals of %reg1235. It is marked as rematerializable with defining instruction: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 8, Mem:LD(8,8) [tmp17641765 + 0] Note that this is the same instruction as above. %reg1097 is marked unspillable (weight set to HUGE_VALF). %reg1461 gets assigned XMM15 by the register allocator. Later on %reg1...