On Wed, 24 Jan 2024 18:51:27 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
> Naive question: the right way to use this would be almost invariably be like > this: > > ``` > if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) { > // fast-path > } > // slow path > ``` > > Right? Yes, I think so. > Then the expectation is that during interpreter and C1, `isCompileConstant` > always returns false, so we just never take the fast path (but we probably > still pay for the branch, right?). Yes, I think so. For C1, we would still prune the "dead" path, because C1 is able to know that `if (false)` is never taken. We do pay with the branch and the method call in interpreter. (There are ways to special-case these intrinsics for interpreter too, if we choose to care.) > And, when we get to C2 and this method is inlined, at this point we know that > either `foo` is constant or not. If it is constant we can check other > conditions on foo (which presumably is cheap because `foo` is constant) and > maybe take the fast-path. In both cases, there's no branch in the generated > code because we know "statically" when inlining if `foo` has the right shape > or not. Correct? Yes. I think the major use would be using `constexpr`-like code on "const" path, so that the entire "const" branch constant-folds completely. In [my experiments](https://github.com/openjdk/jdk/pull/17527#issuecomment-1906379544) with `Integer.toString` that certainly happens. But that is not a requirement, and we could probably still reap some benefits from partial constant folds; but at that point we would need to prove that a "partially const" path is better than generic "non-const" path under the same conditions. I agree it would be convenient to put some examples in javadoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17527#issuecomment-1908736651