On Wed, 24 Jan 2024 18:51:27 GMT, Maurizio Cimadamore <[email protected]>
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
