If I compile this code with the latest ldc2 with -O -release -inline -noboundscheck, the inner loop is unrolled (while gdc unrolls it):


void main() {
    import core.stdc.stdio;

    enum uint n = 1 << 25;

    static immutable uint[5] factors = [101, 103, 107, 109, 113];
    uint c = 0;

    for (uint i = 1; i < n; i++)
        for (uint j = 0; j < 5; j++)
            if (i % factors[j] == 0) {
                c++;
                break;
            }

    printf("%u\n", c);
}


A little cheap unrolling could be present in -O.

Bye,
bearophile

On 26 Mar 2014, at 0:25, bearophile wrote:
> A little cheap unrolling could be present in -O.

I don't think anything is likely to happen here on the LDC side, as it seems to be a question of tuning the LLVM optimizer.

I checked the generated IR and there aren't any obvious issues that would preclude optimization, and the passes selected by "opt" for the highest optimization level do not unroll the loop either.

David

David Nadlinger:

> I don't think anything is likely to happen here on the LDC side, as it seems to be a question of tuning the LLVM optimizer.
>
> I checked the generated IR and there aren't any obvious issues that would preclude optimization, and the passes selected by "opt" for the highest optimization level do not unroll the loop either.

OK, thank you. So later I'll ask to the llvm devs :-)

Bye,
bearophile

David Nadlinger:

> I don't think anything is likely to happen here on the LDC side, as it seems to be a question of tuning the LLVM optimizer.

I was busy for few days, but now I have asked in the llvm channel, and the answer is that currently (unlike GDC) llvm doesn't unroll loops with multiple exits (it might break, it might not; so there are multiple possible exits).

They know about this limitation so perhaps there's not much point in opening a LLVM enhancement request.

Bye,
bearophile