[illwieckz]

Enable optimization on nacl-armhf with Saigo but limit the amount of optimization passes.

We already know that Saigo produces broken ARM executables when optimizing them:

• See: The Saigo-built ARM nexe crashes Unvanquished/Unvanquished#3297

Until now I postponed the investigation, so I has simply disabled the optimization on armhf (but only on armhf) so we could test everything else until this optimization thing is investigated. That intentional optimization disablement is only meant to be temporary and only used on armhf, not on other architectures like amd64 which are fine.

I actually spent some times these days, using -mllvm -opt-pass-limit= to find first pass limit where the build breaks (that is 53696), then I successfully found some optimizations to disable in clang that would unlock to an higher limit. I'm now stuck at 53799 which is my third limit bisect. This is very time consuming and there the limit is probably in hundreds of thousands passes. Of course it's possible that at a time I stumble right on a broken pass that would unlock everything, but no one knows. There are hundreds of different optimizations to checks…

So, I don't know if I will pursue that limit bisect effort. Unless an unexpected breakthrough, I wouldn't exclude that continuing that effort would spend a fulltime job for a complete week or even more, which is not worse the effort, and that I obviously cannot invest.

But since I know that limiting the amount of optimization passes makes possible to produce a sufficiently-optimized build while avoiding the bad optimization combinations, I just implemented in Saigo (patch to come) a variant of -opt-bisect-limit named -opt-pass-limit which does exactly the same but never prints any BISECT diagnostic log, because this new option isn't a diagnostic tool but just a way to arbitrary limit the amount of optimization passes.

This change uses that new Saigo option when detected to be implemented in the said Saigo build, otherwise fallback of complete optimization disablement as a safe fallback.

As said in the comments:

Above limit 53696, the produced Unvanquished cgame is corrupted.
Under limit 21000 (approximation), the performance is not fully recovered.
50000 is selected as a high value with a fair margin.
Set -1 (unlimited passes) to unlock breakage.

If one day we observe a new game change triggers the optimization bug again, we just have to lower the limit.

I did some performance measurement on a Orange Pi 5 (RK3588S, quad-core A76+quad-core A55), I intentionally drastically reduced the graphics quality (640×480 resolution, low preset) to make the CPU performance more obvious.

Here are some performance comparison observed on plat23, default spectator scene:

armhf build	framerate
Native armhf dll with optimization	290 fps
PNaCl armhf with optimization	260 fps
Saigo armhf without optimization	155 fps
Saigo armhf with 50000 optimization limit	265 fps

[illwieckz]

I'll submit the Saigo code later after some clean-up.

[illwieckz]

See the Saigo side:

• llvm: add quiet target-specific optimization pass limit and set a default on ARM saigo-nacl-sdk#18

[illwieckz]

Obsoleted by:

• patches: add llvm-project patch to preserve subtraction in ARM NaCl address expansion saigo-nacl-sdk#19

[illwieckz]

After having submitted this I got new ideas and that led to the breakthrough I wasn't even really expecting anymore. That ride had been wild!