barrett15_74: add workaround for MacOS bug

[proski]

barrett15_74: add workaround for MacOS bug

This fixes failures in barrett15_74 on MacOS 14 with Radeon Pro 560.

Keep 2 extra bits for a.d4 before loop just like it's done later inside
the loop. It may not be necessary mathematically, but it prevents an
optimization bug that turns a.d4 into a random number on MacOS.

Recognize "Radeon Pro 560" that exhibits the issue as GCN4.

[proski]

Apparently & 0xFFFF triggers some incorrect optimization. OpenCL is buggy on MacOS as it's considered deprecated (even printf is flaky). Fortunately, this fix is simple and makes the implementation more consistent - look for another keep 2 extra bits below in the same function.

Note that there is only one other occurrence of 0xFFFF in mfakto OpenCL code, and it's not used as a mask.

[proski]

I don't always have access to the Mac that exhibits the problem, but I tested this PR on an Intel GPU. Self-test with -st2 shows no failures, so the math should be good. The performance of the cl_barrett15_74_gs kernel increases by about 0.34% when averaged over all tested exponents. I don't know if the data is reliable, but it's encouraging to see no degradation.

[proski]

Added a small change to recognize the GPU that exhibits the problem as GCN4. Reference: https://www.techpowerup.com/gpu-specs/amd-polaris-21.g812

[proski]

I made some tests to see if leaving another extra bit would affect any calculations. I disabled all kernels other than barrett15_74 and ran self-tests. It turns out that bit (0x10000) is always zero. In fact, the greatest value of a.d4 & 0x1ffff I observed was 0x4016. For the extra bit to affect calculations, a.d4 & 0x1ffff would have to be 0x10000 or greater, i.e. almost 4 times greater. That's a good margin of safety.