Add options to select the threshold for using rep movs in arraycopy

[a7ehuo]

arraycopyRepMovsByteArrayThreshold

• Byte array copy threshold for using REP MOVS instructions.
• Only supports 32 or 64 bytes

arraycopyRepMovsCharArrayThreshold

• Char array copy threshold for using REP MOVS instructions.
• Only supports 32 or 64 bytes.

arraycopyRepMovsIntArrayThreshold

• Int array copy threshold for using REP MOVS instructions.
• Only supports 32, 64, or 128 bytes.

arraycopyRepMovsLongArrayThreshold

• Long array copy threshold for using REP MOVS instructions.
• Only supports 32, 64, or 128 bytes.

arraycopyRepMovsReferenceArrayThreshold

• Reference array copy threshold for using REP MOVS instructions.
• Only supports 32, 64, or 128 bytes.

[a7ehuo]

@0xdaryl May I ask you to review this change? Thank you!

eclipse-openj9/openj9#19815 depends on this change

@vijaysun-omr @hzongaro fyi

[0xdaryl]

Because these thresholds are never validated against your stated limits, can you confirm no functional failures will occur if someone specifies a value other than the supported limits? If the answer is that functional failures could occur then we'll need some way of validating the range of these options.

Also, since these thresholds are initialized to 0 and only changed if someone uses the option, then isn't 0 also a supported threshold?

[a7ehuo]

CG always initializes the threshold to 32 first. It sets the value from arraycopyRepMovs*ArrayThreshold only when the value specified by arraycopyRepMovs*ArrayThreshold is the supported limit and greater than 32. Otherwise, the value is ignored. There should not be any functional failure if an unsupported limit is set on the command line.

Below is an example of how a threshold is set for long array in OMRTreeEvaluator.cpp:

   threshold = 32;

   switch (elementSize)
      {
      case 8:
         {
         ...
         int32_t newThreshold = cg->comp()->getOptions()->getArraycopyRepMovsLongArrayThreshold();
         if ((threshold < newThreshold) && ((newThreshold == 64) || (newThreshold == 128)))
            {
            // If the CPU doesn't support AVX512, reduce the threshold to 64 bytes
            threshold = ((newThreshold == 128) && !cg->comp()->target().cpu.supportsFeature(OMR_FEATURE_X86_AVX512F)) ? 64 : newThreshold;
            }
         }
         break;

since these thresholds are initialized to 0 and only changed if someone uses the option, then isn't 0 also a supported threshold?

The initial value as 0 in the Options should be fine. It is not used to initialize the value used in CG as mentioned on the above. The value from the command line options is only considered when it is greater than 32.

[0xdaryl]

I understand that threshold is initialized to constant 32, but the new options are used to initialize newThreshold in that code snippet. If the options aren't explicitly set then their value of 0 is very much a part of the equation to determine if threshold needs to be adjusted. That was the source of my question.

My reading of the code concludes that it should be fine though, and you verified that no functional issue will occur with an unsupported value.

[a7ehuo]

Thank you for the clarification! Should the default value for _arraycopyRepMovs*ArrayThreshold in OMROptions be changed to 32 as default instead of 0?

[0xdaryl]

Yes, that seems like a sensible default if that is the minimum each of those options could be.

[a7ehuo]

Addressed in bcf5c45. Ready for another review. Thank you @0xdaryl

[0xdaryl]

Jenkins build all

[0xdaryl]

Jenkins build win,plinux