(especially those with a completely empty upper half of the spectrum)

     1 thread     8 threads
-5   0m26.6009s   0m7.253s
-5p  1m44.983s    0m20.706s
-8   2m10.424s    0m25.829s
-8p  17m37.321s   3m30.797s

     1 thread     8 threads
-5   0m20.809s    0m6.847s
-5p  0m35.891s    0m8.379s
-8   1m46.554s    0m21.323s
-8p  11m30.919s   2m20.278s

I didn't quite get the change, but is it so that the code checks that the residual fits a signed short, and when it does ... much faster?

Ah. So you have just improved a criterion of the following kind:
"This predictor vector cannot possibly create any too big residual from a history of N-bit samples, so we can save time by bypassing the size checks that we are mathematically sure it would anyway pass"?

Compression -4 may be pretty good with a clang compile but high compression and multithreaded stress should be clearly faster with GCC builds.

Ok, i didn't try that.. but luckily, all others do it here. I choose compression "-4" based on the charts and own tests yeeeeeears ago, all resting compression steps ceased to exist for me, i forgot them completely.. and that continues to this day.
But I understand that the code here should primarily be tested under stress conditions of higher compression, where the changes are more pronounced.

i7 3770k, 16gb, 240gb
Busta Rhymes - 829,962,880 bytes

FLAC -8      33.272s  558,662,099 (67.31%)
FLAC -8r8    38.801s  558,185,865 (67.25%)
FLAC -8p    116.991s  558,016,569 (67.23%)
FLAC -8e    117.558s  558,392,936 (67.27%)
FLAC -8pr8  163,238s  557,504,740 (67.17%)
FLAC -8er8  183.193s  557,894,225 (67.21%)
FLAC -8ep   877.759s  557,731,511 (67.19%)
FLAC -8epr8    -          -

@Hakan Abbas : Quite a bit of reference flac's encoding efficiency is in first estimating what model and precision to use, and then encoding only that. But there are brute-force switches. If you want a "lighter -8", try -8M or even -7M. The "M" switch will override the brute-force choice of stereo decorrelation (the "-m" that is usually part of -5-and-up) and use a smart heuristic there as well. You can grind down the encoder pretty much to a halt, trying tons of new different predictor vectors and hoping one of them improves. Settings above -8: https://hydrogenaud.io/index.php/topic,123025.msg1016625.html#msg1016625 . Note the last couple of lines relating it to WavPack's -x4

What those -e -p and -r8 do: 
-e: instead of estimating to choose prediction order (history length) and if applicable, choice of windowing function: Try them all. Since flac 1.4.0 it rarely has much impact on CDDA material, but the estimation procedure seems to be fooled for low-passed material (that includes "bogus upsampling", so much more often the impact is visible for higher sampling rates).
The estimation procedure has been honed and improved over flac's lifetime, and back in the age of 1.1.x it was less trustworthy - and so the "-8" preset did invoke -e back then.
-p: There is a trade-off between coefficient precision and the space needed to store them. Brute-forcing that with -p should not give too much improvement, but sometimes it does better simply because the round-off is sometimes beneficial, so in effect there is an element of "trying more predictors", not just "coarser versions of the same".
-r: the partitioning. The presets have -r3 (max eight partitions per subframe) to -r6 (max sixty-four). The actual choice is brute-forced I think, starting from the finest choice allowed and then merging.
But what is not brute-forced, is the choice of Rice exponent for each partition. It is usually not needed, IIRC it is fast to calculate a choice that "is rarely worse than one away from the optimal", and one away doesn't incure much size penalty.

Edit: By the way, I think you use AVX2 in all HALAC builds? FLAC speeds do depend on both compile and CPU architecture. Here are some results comparing builds: https://hydrogenaud.io/index.php/topic,123025.msg1029768.html#msg1029768