similar to: [LLVMdev] Loading of immediates into registers

Hi, While investigating a performance issue with an internal codebase I came across what looks to be poor register allocation. I have constructed a small(ish) reproducible which demonstrates the issue (see test.ll 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

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

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

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

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

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

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

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 May 3, 2011, at 12:03 PM, David A. Greene wrote: >> >> The greedy allocator is trying to pick registers so inner loops are as >> small as possible, but that is not always the right thing to do. > > How does it balance that against spill cost? I added the CostPerUse field to the register descriptions. The allocator will try to minimize the spill weight assigned to

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

On Sun, Feb 27, 2011 at 01:29:25AM +0100, Joerg Sonnenberger wrote: > +let Predicates = [OptForSize] in { > +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; > +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; > +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8 addr:$dst, -1)>; > +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >>> The greedy allocator is trying to pick registers so inner loops are as >>> small as possible, but that is not always the right thing to do. >> >> How does it balance that against spill cost? > > I added the CostPerUse field to the register descriptions. The > allocator will try to minimize the

On Sat, Feb 26, 2011 at 02:04:54PM -0800, Jakob Stoklund Olesen wrote: > > On Feb 26, 2011, at 1:36 PM, Joerg Sonnenberger wrote: > > > On Sat, Feb 26, 2011 at 01:07:39PM -0800, Jakob Stoklund Olesen wrote: > >> > >> You may want to consider using xorl+decl instead. It is also three > >> bytes, and there are no false dependencies. The xor idiom is

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7,

Thanks for the tip! I looked into it and it looks like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even

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

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: > >> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> >> So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I >> would just follow the chains implied by the SibValueInfo Deps array? >> Basically, I want to find