Zaara Syeda via llvm-dev
2017-Nov-15 22:17 UTC
[llvm-dev] RFC MachineLICM to hoist invariant stores
Hello, I’m looking at MachineLICM and running into a limitation of not hoisting instructions that store a constant value to a constant spot on the stack. I see this example in the case of indirect calls for PowerPC. Indirect calls on PPC must be surrounded by instructions that save and restore the TOC (similar to the GOT) pointer. This pointer is in register X2 and will not change throughout the function. %vreg12<def> = COPY %X2; G8RC:%vreg12 STD %vreg12, 24, %X1; mem:ST8[Stack+24] G8RC:%vreg12 This currently can't be hoisted because: 1. It is a store instruction 2. It uses a physical register (the stack pointer register - X1) 3. The copy that defines the physical register being stored isn't profitable to hoist As a proof of concept, I’ve relaxed these conditions to catch these loop invariant stores by using the fact that registers X1/X2 satisfy isCallerPreservedPhysReg(). With these relaxations I get the following results in SPEC: Benchmark | Improvement | # of Hoists dealII |0.10 % |1203 h264ref |11 % |347 Gcc |1.42 % |135 xalancbmk |0.86 % |3886 Astar | -2.39% | 1 Astar here is an outlier where we see a degradation. In this case, the store was hoisted out of an if statement that is executed infrequently compared to the outer code. This results in the store to r2 being executed more times dynamically. I would like to add TargetInstrInfo hooks like isInvariantStore(MachineInstr &) and isCopyFeedingInvariantStore(MachineInstr &) that would tell MachineLICM that the two instructions are safe and profitable to hoist. Please advise if adding the target hooks is a good solution and if other targets would be interested in such hooks, or whether I should be take a different approach. Thanks, Zaara Syeda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171115/c7bf807d/attachment.html>