On Thu, 3 Mar 2022 12:30:29 GMT, Andrew Haley <a...@openjdk.org> wrote:
> > ``` > > * There are a few minor regressions (~5%) in the x86 implementation on > > `encode-/decodeLatin1Short`. Those regressions disappear when mixing > > inputs, for example `encode-/decodeShortMixed` even see a minor > > improvement, which makes me consider those corner case regressions with > > little real world implications (if you have latin1 Strings, you're likely > > to also have ASCII-only strings in your mix). > > ``` > > I'm not sure that we can disregard such cases. You're probably right, but > it'd be interesting to know the actual cause of the problem, perhaps with > perfasm. Or do you know already? Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231
