[llvm-dev] RFC MachineLICM to hoist invariant stores

[Zaara Syeda via llvm-dev]

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>