Remove UNEXPECTED from typed property checks

[mvorisek]

as pointed out in #13100 (comment)

currently, I would say typed properties are even more used than non-typed :)

[mvorisek]

Please review carefully, I did my best, but there might be more places to remove. Also, I wonder if any improvement can benchmarked.

If this really help, maybe all ZEND_TYPE_IS_COMPLEX(...) calls sould be wrapped in UNEXPECTED()? (as complex types are definitely less common than no/simple/simple nullable types)

[Girgias]

A zend_type is complex nearly all the time. As a type that contains a class name will also be considered complex, the only types which are simple are ones that just contain built-in types (and those can be unions) so no. Having a type be complex is extremely common.

[dstogov]

I would be great to see how this affects performance of different applications.

[dstogov]

I don't see any visible performance difference on bench.php, wordpress, symfony hello and symfony demo.

[mvorisek]

If my understanding of the change is correct, the UNEXPECTED (and expanded compiler flag) is used to rearrange if/else, ie. if else is "expected", the if/else is swapped to put the else code first to avoid jump on a call when the CPU branch predictor is cold.

So no huge change is expected, I wonder if there will be any significant performance difference if all EXPECTED/UNEXPECTED will be dropped or even swapped.

[dstogov]

Not only swapped, but also sometime move unexpected code into .cold section.
This affects size and locality of the .hot VM code and may cause unrelated stalls.

I don't object against this.

[iluuu1994]

Not only swapped, but also sometime move unexpected code into .cold section.

I checked that when we last spoke about this, and it doesn't seem like any of the UNEXPECT(prop_info) cases lead to eviction to .cold.txt, so removing these didn't make a difference to the generated assembly, at least for GCC 13. I still think removing these is the right thing at this point.

[mvorisek]

If there are no more questions let's merge this PR, I have no write permission to do it by myself.

[dstogov]

I don't object.

[iluuu1994]

Thanks @mvorisek!