Check feature instead of Flag for VFE1 facility

[r30shah]

Check the feature query for VFE1 when checking if opcode is supported
for SIMD or not instead of flags, which are not maintained and would be
cleaned up.

Signed-off-by: Rahil Shah rahil@ca.ibm.com

[r30shah]

@joransiu Can I please get your review on this? While collecting performance results for Vector API JEP on Linux on Z15, I was seeing an issue where the _flags for supporting VectorFacilityEnhancement1 was not set. Further checking the code-base, I do not see we set the _flags at all [1] and we set the _features through port library [2].

@Spencer-Comin changes in eclipse-openj9/openj9#14535 might be falling victim of same issue, can you check, if you are getting VFMA generated for Float on Z14?

[1]. https://github.com/eclipse/omr/blob/edf2ae5033cb412348dbeb74d31bab2d26fe933d/compiler/z/env/OMRCPU.cpp#L516-L535
[2]. https://github.com/eclipse/omr/blob/edf2ae5033cb412348dbeb74d31bab2d26fe933d/compiler/z/env/OMRCPU.cpp#L105

[joransiu]

I was seeing an issue where the _flags for supporting VectorFacilityEnhancement1 was not set. Further checking the code-base, I do not see we set the _flags at all [1] and we set the _features through port library [2].

This is quite odd. It's not just VectorFacilityEnhancement1 that doesn't set the respective _flags. The other setSupports h/w facility seemed orphaned too. I tried going back in history, and see that prior to migration of the CPU features from OpenJ9 to OMR, we set the flags : https://github.com/eclipse-openj9/openj9/blob/4acd33ce24d2148092e4a750a0ad9603717ef740/runtime/compiler/z/env/J9CPU.cpp#L333-L336

That said, now we set the cpu _features as you noted, specifically from here for VEF1: https://github.com/eclipse/omr/blob/master/port/unix/omrsysinfo.c#L1647-L1655

We probably should clean up the stale getSupports/setSupports H/W features from OMRCPU.cpp to avoid future confusion.

[r30shah]

@joransiu Looking at the code base, we only used the getSupport facility for the VFE1, all of the other places we were using supportsFeature, so there is not consumer of _flags on Z right now. Before cleaning up I wanted to check when we moved to feature and bump into this issue [1], which outlines the work done to migrate processor detection from OpenJ9 to OMR. Looking at the second last comment from Filip [2], it seems like last thing we needed to get done was to hookup portLib to compiler so we can get rid of old flags check (Which seems to be useless right now as we never set the flags at all and that query would return false).

[1]. #4339
[2]. #4339 (comment)

[Spencer-Comin]

@Spencer-Comin changes in eclipse-openj9/openj9#14535 might be falling victim of same issue, can you check, if you are getting VFMA generated for Float on Z14?

Looks like it's using MAEBR:

import java.lang.Math;
import java.util.Random;

class TestFMA {
	float unitTest(float a, float b, float c) {
		return Math.fma(a, b, c);
	}

	public static void main(String[] args) {
		TestFMA uut = new TestFMA();
		Random rand = new Random();

		for (int i = 0; i < 10000; i++) {
			uut.unitTest(rand.nextFloat(), rand.nextFloat(), rand.nextFloat());
		}
	}
}

> java -version
openjdk version "11.0.16-internal" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16-internal+0-adhoc.jenkins.BuildJDK11s390xlinuxNightly)
Eclipse OpenJ9 VM (build master-50dc5e987b4, JRE 11 Linux s390x-64-Bit Compressed References 20220718_330 (JIT enabled, AOT enabled)
OpenJ9   - 50dc5e987b4
OMR      - edf2ae5033c
JCL      - 0a3801d7bd6 based on jdk-11.0.16+7
> java -Xjit:"dontInline={*unitTest*},{*unitTest*}(disableInlining,traceFull,log=reference.log)" -Xshareclasses:none TestFMA

From instruction selection in log:

 n7n      (  0)  treetop                                                                              [     0x3ff17004770] bci=[-1,3,6] rc=0 vc=433 vn
 n6n      (  1)    fcall  java/lang/Math.fma(FFF)F[#389  final static Method] [flags 0x20500 0x0 ] (in FPR_0032) ()  [     0x3ff17004720] bci=[-1,3,6]
 n44n     (  0)      ==>fRegLoad (in FPR_0034) (SeenRealReference )
 n43n     (  0)      ==>fRegLoad (in FPR_0033) (SeenRealReference )
 n42n     (  0)      ==>fRegLoad (in FPR_0032) (SeenRealReference )
------------------------------

 [     0x3ff17152140]                          MAEBR   FPR_0032,FPR_0033,FPR_0034

[r30shah]

@Spencer-Comin just to confirm, you tried this on Linux on Z14 right? Where we should be using VFMA ?

[r30shah]

@Spencer-Comin if this is the same case, then Can I request you to fix the Math.fma evaluators test it out? If everything is OK, please open up PR with the fix.
Also I would appreciate if you can confirm eclipse-openj9/openj9#14535 (comment) was generated correctly (i.e, the VFMA instruction was generated for Float type when you collect the throughput with your benchmark)

[r30shah]

Jenkins build zlinux zos

[r30shah]

@0xdaryl Can I request you to merge this change as now jenkins builds are done and Joran has reviewed changes?