[PATCH] D36432: [IPSCCP] Add function specialization ability

Matthew Simpson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 9 12:13:41 PDT 2017


mssimpso added a comment.

In https://reviews.llvm.org/D36432#837082, @efriedma wrote:

> > It could be the case that specialization enables further propagation, which then enables additional specialization, etc.
>
> This doesn't really happen at the moment.  After you specialize a function, you aren't resetting the solver, so everything that's overdefined will stay overdefined.


That's right. I think I mentioned this in my response to Davide's comments. This is a current limitation, but is something I think we will want to work towards.



================
Comment at: lib/Transforms/Scalar/SCCP.cpp:2279
+    DEBUG(dbgs() << "SPECIALIZING FUNCTIONS\n");
+    SolveForConstants |= FS.specializeFunctions();
   }
----------------
efriedma wrote:
> mssimpso wrote:
> > efriedma wrote:
> > > This loop doesn't work the way you want it to.  IPSCCP isn't actually complete until the "while (ResolvedUndefs)" loop finishes, and specializing based on a partially unsolved Solver probably won't give you the results you want.
> > I'm not sure this is really a problem. Sure IPSCCP isn't yet complete, but `ResolvedUndefsIn` only moves values from unknown to constant. If an actual argument does become constant while resolving undefs, we should analyze the corresponding (formal argument, constant) pair in `getSpecializationBonus` the next time we visit the function when looking for specialization opportunities.
> > 
> Moving a value from undef to constant can move dependent values from constant to overdefined.  So you could end up cloning a function, and then fail to actually do any useful constant propagation into the cloned function.
Ah, right. I think I see what you mean now.


https://reviews.llvm.org/D36432





More information about the llvm-commits mailing list