On Tue, 8 Mar 2022 17:01:09 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> Can we change the optimizer so that the strength reduction happens only >> after all transformations have settled? Carelessly changing a multiplication >> to a shift as today may hurt a lot of potential optimisations. >> Thanks. > >> Can we change the optimizer so that the strength reduction happens only >> after all transformations have settled? Carelessly changing a multiplication >> to a shift as today may hurt a lot of potential optimisations. Thanks. > > Yes, it's troubling that making a constant non-foldable can lead the JIT down > a path that ultimately pessimizes the end result (as observed here). If we > could train the JIT to avoid this pitfall and get to the improvement observed > in my experiment here without any changes to `String.java` then that'd be > great. > @cl4es Yes, we would need to carefully measure the impact for small array > sizes (similar to what we had to do when the array mismatch intrinsic was > implemented and applied to array equals). My sense is to focus on the > intrinsic and also look for potential opportunities like @merykitty points > out, as that is where the larger impact is, although it is more work! Right, I'm not too thrilled about the prospect of moving ahead with the de-constantification as an alternative patch here. It's such a crutch, but it's also simple and has no obvious downsides as of right now. I think it was a useful experiment to see where some of the gain observed in the unroll might be coming from. The degradation on many smaller `Strings` in the unrolled versions is a concern that I think might be a blocker, though. Short Strings are excessively common as keys in hash maps et.c.. Feels like none of the alternatives seen here so far is really _it_. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700
