String intrinsics defunct on arch != amd64 after 8141132: JEP 254: Compact Strings

Christian Thalinger christian.thalinger at oracle.com
Tue Dec 15 03:11:23 UTC 2015


> On Nov 30, 2015, at 8:54 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi,
> 
> I'm currently trying to fix the String intrinsics
> (SpecialStringCompareTo, SpecialStringEquals, SpecialStringIndexOf) on
> ppc64 after change "8141132: JEP 254: Compact Strings" - at least for
> the case where the strings are not compressed (i.e. UTF16 byte
> arrays).
> 
> For SpecialStringCompareTo and SpecialStringEquals this was not too
> hard, but when I wanted to test the intrinsics for
> SpecialStringIndexOf I realized that they never got generated. I think
> it is because of this code in library_call.cpp
> 
> bool LibraryCallKit::inline_string_indexOf(StrIntrinsicNode::ArgEnc ae) {
>  if (!Matcher::has_match_rule(Op_StrIndexOf) || !UseSSE42Intrinsics) {
>    return false;
>  }
> 
> If "UseSSE42Intrinsics" is false, which it always is on ppc64,
> inline_string_indexOf() will always return false.
> 
> So I wonder how this code is supposed to ever work on non-amd64 architectures?
> 
> Moreover, "UseSSE42Intrinsics" is clearly a architecture-dependant
> option. I already wondered that according to vm_version_aarch64.cpp it
> seems to exists on aarch64 (is this really true Andrew?). But it's
> surely not available on PowerPC, SPARC, ...
> 
> So I think "UseSSE42Intrinsics" should be at least guarded with
> X86_ONLY/AARCH64_ONLY in shared files. Probably even better would be
> to move the check right into the Matcher.
> 
> What do you think?

That looks like bad design to me.  We should find another way to do this.  Your suggestion to move it into the matcher sounds reasonable.

> 
> Regards,
> Volker



More information about the hotspot-compiler-dev mailing list