Do not unroll loops on ReleaseSmall

[jedisct1]

Trivial fix for #7048, verified to work on the given test case.

Fixes #7048

[LemonBoy]

Well well well, I think the proper solution would be to introduce a -fno-unroll-loops (for gentoo haters) so that people who really need it and people who think they're smarter than the compiler can toggle the option in the pipeline.

The cooler solution would be to inhibit the unrolling only for specific loops with some kind of annotation, much better than disabling this optimization for the whole compilation unit.

[jedisct1]

Do we really want to introduce more knobs? The intent of ReleaseSmall currently seems to be to produce the smallest possible code (thus the opinionated choice of -Oz and not -Os), and in this context, not unrolling loops by default would make sense.

How about introducing an intermediate size reduction level (-Os equivalent, without loop unrolling being disabled) instead?

[jedisct1]

Annotations to enable/disable unrolling of individual loops (similar to #pragma unroll(x)) independently from the global settings would indeed be neat!

[LemonBoy]

Do we really want to introduce more knobs? The intent of ReleaseSmall currently seems to be to produce the smallest possible code (thus the opinionated choice of -Oz and not -Os), and in this context, not unrolling loops by default would make sense.

Well the performance impact on the generated code may be non-negligible and changing how ReleaseSmall behaves leaves the user with no way to opt-out of this change.

How about introducing an intermediate size reduction level (-Os equivalent, without loop unrolling being disabled) instead?

That may be a good compromise.

[jedisct1]

The hardest part would be to name that new optimization level.

[andrewrk]

The cooler solution would be to inhibit the unrolling only for specific loops with some kind of annotation, much better than disabling this optimization for the whole compilation unit.

I believe this is #978.

I'm opposed to adding a new release mode or more global knobs. Is there a real world use case to consider that is not satisfied with this patch + the planned #978?

[jedisct1]

-Os is a perfect fit for WebAssembly, as code generators and runtimes currently have limited optimization passes, yet size is important.

In ran quite a few benchmarks ([1] [2]) a while back on multiple WebAssembly runtimes; -O2 and -Os had very similar performance, but having smaller modules to download is an obvious benefit.

[marler8997]

Why | instead of ||?

[LemonBoy]

I believe this is #978.

That proposal has some flaws:

• LLVM only allows optsize and optnone, meaning you can only disable the optimization pass for a given function,
• The minimum granularity ensured by the backends is usually a function, not arbitrary chunks of code,
• The idea here was to let the user fine-tune how the loop is unrolled, having @optimizeFor(.ReleaseFast) do it automagically is probably not fine-grained enough (and, as stated before, you can't make LLVM optimize a single function only)

What I had in mind was something like the following:

fn @setScopeOptions(opt: union(enum) {
    // function-level options, they can only be applied in a fn scope
    Func: struct {
        stack_alignment: ?usize // Replaces setStackAlign
        enable_stack_canaries: bool,
        runtime_safety: bool, // Can also replace setRuntimeSafety
        optimize_hint: enum { None, Compact, NoOptimizations }, // Tentative naming, don't kill me
        // Other options go here
    },
    Loop: struct {
        force_unroll: bool,
        force_unroll_count: usize,
    },
    // Who knows what else we may need
}) void;

This way we can drop a few special-cased builtins and allow us to introduce as many new options we want with ease.