Split out the TYPE_CHECK implementation for resources

[TysonAndre]

• The old version is harder to reason about,
  due to having different handling for resources.

  Opcache has to check for MAY_BE_RESOURCE when transforming opcodes,
  JITing operations, etc.

• @nikic suggested considering a separate opcode in Optimize $a = !is_string($x) in opcache #4906

Performance impact: no improvement/worsening,
unless hypothetically if is_resource and is_int calls were to alternate.

• I tried optimizations such as avoiding SAVE_OPLINE when possible in
  TYPE_CHECK. This somehow made performance worse for the below benchmark
  (possibly due to larger code size).

Making this COLD might make more sense - I doubt a typical application would
be bottlenecked by is_resource.

E.g. this case was unaffected for loopnotnull_isnull(0, 30000000);

function loopnotnull_isnull($a, $b) {
  $count = 0;
  for ($i = $a; $i < $b; $i++) {
      if (is_null($i)) {
          $count++;
      }
  }
  return $count;
}

NOTE: opcache.file_cache should be cleared by developers after this
commit

[cmb69]

This appears to cause multiple test failures. Could you please have a look?

[TysonAndre]

This appears to cause multiple test failures. Could you please have a look?

The code I copied was still using extended_value in opcache, which should have been replaced with MAY_BE_RESOURCE. Fixed.

[TysonAndre]

@dstogov - thoughts on this? I'd felt this would make the TYPE_CHECK implementation in opcache and the JIT simpler and less bug prone to optimize, as mentioned in #4906 (comment) (and make the optimizations mentioned in that PR easier)

[dstogov]

The idea looks fine. The implementation (especially JIT) seems incomplete.
I may take care about JIT changes.

[cmb69]

After that long time, this PR has merge conflicts. I'm not super convinced that optimizing for resources makes much sense, since these need to go anyway, but maybe it's still reasonable, given that they will still stay for a long time.

[github-actions]

There has not been any recent activity in this PR. It will automatically be closed in 7 days if no further action is taken.