search for: rematerializability

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

...the spill weight which is used to determine whether one interval should evict another. If the live interval is rematerializable the spill weight is halved (multiplied by 0.5). From what I can see, this calculation is the only place in the greedy register allocator (as opposed to the spiller) where rematerializability is considered. So rematerializable intervals should be less important than non-rematerializable intervals, assuming similar number of uses, size of range, etc. However, there appears to be a flaw: * A rematerializable interval once split is no longer rematerializable * The isRematerializable ch...

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

I do have a reproducer, but it's not for the faint of heart :) This is from a large and messy C file (Perlbench's regexec.c), reduced by bugpoint down to 1050 lines of IR. Perhaps I can paste it on pastebin. Just for fun, I added some debug dumps for machine instructions that spill registers (i.e. return non-zero from MachineInstr::getFoldedSpillSize()) that are fed by load-immediates and

Thanks for the reduced test case, I’ll try to take a look by the end of the week. > On Feb 20, 2019, at 6:53 PM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Finally managed to reduce this to something manageable: https://godbolt.org/z/Hw529k <https://godbolt.org/z/Hw529k> > > On line 40 of the output, we have a load-immediate to put zero into R3. Then we

I am a bit confused how the rematerialization works. It seems currently in our backend we get lots of 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

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.

On 22-Jul-08, at 1:22 PM, Dan Gohman wrote: > On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: >> - build a custom alias analysis pass that indicates that these loads >> never alias with any stores in a given function >> - declare these globals as external constants within the module > > If you can convince yourself that no interprocedural optimization > will ever

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I

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

...lso > noticed that the documentation for > TargetInstrDesc::isRematerializable() says "This flag is deprecated, > please don't use it anymore" -- could you explain what replaces it? I think the idea is to move towards having more complete instruction descriptions so that the rematerializability of an instruction can be inferred instead of being an explicit flag, but I don't know what stage this transition is in. Dan

I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. The target's load and store instructions affect the condition code register (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

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 the module. There seem to

Having worked with a few people to better understand the tablegen descriptions of instructions and patterns in LLVM's backend and looking at x86's pretty heavily, I have some questions: 1) Are there instruction definition flags that are really just "when needed"? I'm thinking of things like "mayLoad" which is really alarmingly missing from a bunch of instructions

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

On Jun 3, 2013, at 6:05 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. > > The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and

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

Roman Levenstein wrote: > Hi again, > > Now, after I fixed the graph coloring regalloc bug that was triggered > by the ARM target, I continue testing and found another bug, this time > on the XCore target. First I thought that it is again specific to my > register allocator, but it seems to be trigerred also by LLVM's > linearscan register allocator. > > I don't

Ok, this is a rather complicated e-mail. Please ask questions if you don't understand something. I've come across an interesting problem. I'm merging our graph coloring allocator with the code from trunk as of late last week. I have a code where a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is spilled and at least one use is rematted. The remat def