[PATCH] Ephemeral values for LLVM invariants

[hfinkel at anl.gov]

================
Comment at: lib/Analysis/CodeMetrics.cpp:77
@@ +76,3 @@
+             J != JE; ++J) {
+          if (isSafeToSpeculativelyExecute(*J))
+            WorkSet.push_back(*J);
----------------
Chandler Carruth wrote:
> Why being "ephemeral" is equivalent to being safe to speculate isn't immediately obvious to me. might be nice to add a comment at least ...
The essential property of an "ephemeral" instruction is that it will go away (no actual code will be generate corresponding to the operation it represents). If something is not safe to speculate, then it will not really go away because it might have side effects. Does that make sense?

================
Comment at: lib/Analysis/IPA/InlineCost.cpp:1106
@@ +1105,3 @@
+  DenseSet<const Value *> EphValues;
+  CodeMetrics::collectEphemeralValues(&F, EphValues);
+
----------------
Chandler Carruth wrote:
> Oof, so, we can't do it this way in the inline cost analysis for terrible reasons.
> 
> The reason why inline cost analysis ends up duplicating so much code from code metrics is because an essential property of inline cost analysis is that the amount of work done should be bounded by the constant threshold, not by the size of the function (or basic block). This is important because we may end up doing a linear number of calls to compute the inline cost where the linear factor would go quadratic if we do a linear amount of work here. =/
> 
> This is particularly problematic for ephemeral values because their very nature is defined backwards. I'm happy with this as an initial implementation but it should have a "FIXME" to revisit this before we start emitting them really heavily.
Alright; we'll need to think of a better way. What if we did this only once per function, and cached the result. When a function is inlined, the inliner updates a ephemeral value map so the list of instructions in the caller can be updated. Now it is possible for inlining to introduce new ephemeral values in the caller, but only from things that used to be function arguments so we could then do a more-limited propagation.

The problem is that the scan is already linear, so I'd be ruining your complexity guarantee as soon as the functionality is committed regardless of the number of invariants.

http://reviews.llvm.org/D180