[PATCH] D16435: [RS4GC] Effective rematerialization at non-entry polls

[Philip Reames via llvm-commits]

reames created this revision.
reames added reviewers: JosephTremoulet, sanjoy, igor-laevsky, mjacob.
reames added a subscriber: llvm-commits.
Herald added subscribers: mcrosier, sanjoy, MatzeB.

This is an attempt at addressing 26223.  Specifically, try to avoid unfortunate register spilling by trying to place rematerializations introduced by rewrite-statepoints-for-gc in order to maximize folding and simplification opportunities rather than to minimize execution frequency.  

If we have a bit of code like this:
%addr = gep %o, 8
loop {
  if (poll) {
     safepoint();
  }
  load %addr
}

We currently end up rewriting this as:
%addr = gep %o, 8
loop {
  %addr1 = phi (%addr, %addr2)
  if (poll) {
     safepoint();
     %remat = gep %o.relocated, 8
  }
  %addr2 = phi (%addr1, %remat)
  load %addr2
}
This ends up forcing us to rematerialize the address explicitly and likely will cause us to spill/fill the address if register constrained.  This creates a bunch of dependent loads (fill from stack, load from result) which show up as hot in a couple of benchmarks.  

A much better result would be:
%addr = gep %o, 8
loop {
  if (poll) {
     safepoint();   
  }
  %remat = gep %o.relocated, 8
  load %remat
}

This version allows the GEP to be folded directly into x86's native addressing modes.  

(Note: For conciseness, I'm not writing the phis for relocating %o, assume they're all there.)

The particular heuristic chosen here is to push each given remat as late as possible.  This has the effect of moving remats closer to uses and preventing the creation of unnecessary and confusing PHI nodes.  Empirically, this does appear to help in some of the benchmarks when I encountered this, but I'm getting increasing uncomfortable with the coupling between RS4GC and CGP.  In particular, a better version of this heuristic is already present in CGP.  

I think we should probably take this incremental step, but before going much further, factoring the code to share parts of the implementation of CGP might be a good idea.  The generally problem is that many CGP transforms are hard to perform after RS4GC has run.  It may make sense to selectively run them before hand.  

http://reviews.llvm.org/D16435

Files:
  lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
  test/Transforms/RewriteStatepointsForGC/remat-schedule.ll
  test/Transforms/RewriteStatepointsForGC/rematerialize-derived-pointers.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D16435.45619.patch
Type: text/x-patch
Size: 12767 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160122/ef2c89a3/attachment.bin>