Clang 11 or above generates larger code at -Oz

[rilysh]

Example:

int loop_body(int n)
{
	int i, j = 0;
	for (i = 0; i < n; ++i) {
		for (; j < n; ++j) {
			j = n + 1;
		}
	}

	return j;
}

For the initial part, Clang 11 or above generates some additional instructions, while with Clang 10, it's relatively better.

With Clang 11 or above

loop_body:
        lea     ecx, [rdi + 2]
        xor     edx, edx
        test    edi, edi
        mov     esi, 0
        cmovg   esi, edi
        xor     eax, eax

(Why not xor esi, esi, which is just 2 bytes for encoding?)

And with Clang 10 or below

loop_body:
        lea     ecx, [rdi + 2]
        xor     edx, edx
        xor     eax, eax

I'm not exactly sure what's the point of that additional testing, GCC seem to avoid this (-Oz).

Testcase:
https://godbolt.org/z/a33nv18K1 (with Clang)
https://godbolt.org/z/3sfWKGxvq (with GCC)

[Validark]

Don't mean to speak out of turn here, but isn't your code equivalent to this?

int loop_body(int n)
{
    if (n <= 0) return 0;
    return n + 2;
}

In assembly:

loop_body:
        lea     ecx, [rdi + 2]
        xor     eax, eax
        test    edi, edi
        cmovg   eax, ecx
        ret

No looping is necessary

[rilysh]

Now you're checking for if n <= 0 which means the additional test is necessary to do.
I've used the loop to initialize two additional variables, i and j which in theory should just be two xor operations before starting the loop, but Clang does more than that.

It also for some reasons loads ecx, [rdi + 2] at the very beginning, which now will require the value in address of [rdi + 2] to be moved in eax inside the loop

.LBB0_2:
        mov     r8d, eax
        mov     eax, ecx
        cmp     r8d, edi

can be

       lea      eax, [rdi + 2]
.LBB0_2:
        mov     r8d, eax
        cmp     r8d, edi

as it doesn't have any side effects and makes it shorter (when comparing the size).

[Validark]

Do you think my equivalent code has different behavior? Are you using your nested loops exactly as you've posted here?

[rilysh]

At least yes for the initial part. There are additional steps where Clang generated larger instructions via this loop, and that's what I want show, thus the title.
Yes, I'm using them exactly (and same #112421 (comment)) as I've posted here.

[Validark]

To be clear, I'm saying that the code I provided is equivalent to your whole function, not just the loop prologue.

[rilysh]

Yes but n isn't known at compile time, and Clang doesn't know side effects of this loop, so it can't just drop it.
What I'm saying is that generated assembly for the loop is rather inefficient. That includes the initial part and some portion in the body of the loop as well.

[Validark]

I still think my version of your function produces the same results. I think I am not understanding what you are communicating, sorry. Hopefully someone who works on LLVM will be able to help you.

[rilysh]

I'm closing it, this is now fixed in the private fork.
Someone else will send the patch to the upstream.