CI Benchmark indicates a slight slowdown. Can anyone with a “reliable CPU” do another non-valgrind check to see if this actually resulted in regressions? My CPU is notoriously bad at benchmarking.

❯ b 50 --mode=cycles 'sapi/cli/php-old -n benchmark/repos/symfony-demo-2.2.3/public/index.php' 'sapi/cli/php-new -n benchmark/repos/symfony-demo-2.2.3/public/index.php'
Old:       1.694 G ± 991.360 k (0.059%) 
New:       1.696 G ± 1.041 M (0.061%)
Diff:      2.264 M (0.134%)
T-test:    5.679
P-value:   0.001

First test looks to be slower.

Edit: Second run approx. confirms.

❯ b 50 --mode=cycles 'sapi/cli/php-old -n benchmark/repos/symfony-demo-2.2.3/public/index.php' 'sapi/cli/php-new -n benchmark/repos/symfony-demo-2.2.3/public/index.php'
Old:       1.697 G ± 1.114 M (0.066%)   
New:       1.698 G ± 957.368 k (0.056%)
Diff:      1.337 M (0.079%)
T-test:    3.282
P-value:   0.008

Can relate

Coming from your other PR, I see now why you submitted this.
I don't know why this worsens performance, but indeed the benchmark seems to indicate now a deviation higher than noise.
It could be many different reasons, from alignment of functions/loops to bad compiler spill/rematerialization decisions...

Given that this PR seems to lead to a unclear performance degradation, I'd prefer not to merge it. We can investigate why it happens, and potentially create a bug report if we can identify a compiler-related culprit. It may also be alignment-related, as Niels mentioned. I have thought about a way to align the function offsets of two binaries when I encountered this issue myself, given that -falign-functions and friends didn't help. One way might be to build the binaries, inspect the elf-file and calculate the necessary nops to insert, and then use llvm-bolt's --pad-funcs-before flag. Not sure whether that will work. Suggestions are welcome.

Also, for completion's sake: I tried to apply pure and const with an automated script last year:
master...iluuu1994:php-src:script-fix-const-pure-attributes

The entire PR showed a big degradation, although I don't remember by how much nor how I measured it. It would ofc be great if this unlocked some optimization opportunities. In that case, it might be better to go the automated route, rather than applying it bit-by-bit by hand.