Search
LDC 1.5-1.6 huge degradation of optimization
Nov 27
kinke
Nov 30
kinke
Nov 30
Joakim
Dec 01
kinke
```Hello!

I have found that LDC1.5-1.6 generate unoptimized code in contrast to LDC1.3-1.4 in some cases. I tried to extract the example and make it as short as possible. The goal is to get the compiled code with avx(2) instructions.

Here is the source of tst.d with comments to demonstrate the problem.

// tst.d

import ldc.attributes;

// ldc1.3-1.4 generate higly optimized code with avx2 instructions
// ldc1.5-1.6 generate the code without any vector instructions
// the command line: ldc2 tst.d -m32 -O3 -release -output-s

alias Arr = ubyte[16][20]; // 20 of 16-ubyte vectors

import ldc.attributes;

@target("avx2") @nogc pure
auto distance(ref const Arr t1, ref const Arr t2)
{
int[20] res = void;
int sum;
foreach(t, ref r; res) {
int sv=0;
foreach(i; 0 .. 16) // the main cycle to be optimized with avx2 instructions
sv += (t1[t][i]-t2[t][i])^^2;
r = sv;
// by uncommenting the following assignmet the avx2 optimization is turned on in ldc 1.6
// sum += sv;
}
return sum + res[10]; // returm some dummy sum
}

/* ldc1.3 (avx2 instructions are used)
LBB0_1:
vpmovzxbd	-8(%ecx), %ymm0
vpmovzxbd	-8(%eax), %ymm1
vpmovzxbd	(%eax), %ymm2
vpsubd	%ymm1, %ymm0, %ymm0
vpmovzxbd	(%ecx), %ymm1
vpmulld	%ymm0, %ymm0, %ymm0
vpsubd	%ymm2, %ymm1, %ymm1
vpmulld	%ymm1, %ymm1, %ymm1
vpaddd	%ymm0, %ymm1, %ymm0
vextracti128	\$1, %ymm0, %xmm1
vpaddd	%ymm1, %ymm0, %ymm0
vpshufd	\$78, %xmm0, %xmm1
vpaddd	%ymm1, %ymm0, %ymm0
vphaddd	%ymm0, %ymm0, %ymm0
vmovd	%xmm0, (%esp,%edx,4)
incl	%edx
cmpl	\$20, %edx
jb	LBB0_1
*/

/* ldc1.6 (avx2 instructions aren't used)
LBB0_1:
movl	%edx, (%esp)
movzbl	-15(%ecx), %esi
movzbl	-15(%eax), %edx
movzbl	-14(%ecx), %edi
subl	%edx, %esi
movzbl	-14(%eax), %edx
imull	%esi, %esi

... ; skipped

imull	%ebp, %ebp
movl	36(%esp), %ebp
imull	%ebp, %ebp
movl	32(%esp), %ebp

... ; skipped

imull	%edx, %edx
movl	(%esp), %esi
movl	%edx, 48(%esp,%esi,4)
movl	(%esp), %edx
incl	%edx
cmpl	\$20, %edx
jb	LBB0_1
*/
```
```On Monday, 27 November 2017 at 10:41:44 UTC, Igor Shirkalin wrote:
> Hello!
>
> I have found that LDC1.5-1.6 generate unoptimized code in contrast to LDC1.3-1.4 in some cases. I tried to extract the example and make it as short as possible. The goal is to get the compiled code with avx(2) instructions.

LDC 1.5 and 1.6 both come with LLVM 5.0.0, so it looks as if this is an LLVM regression.
This can be shown by compiling to unoptimized textual LLVM IR (that's the LLVM IR LDC generates, before LLVM optimizations) and comparing it across LDC versions. I did that for LDC 1.4 and 1.6, and the relevant IR is identical:

ldc2-1.4.0-win64-msvc\bin\ldc2 -release -output-ll perf.d -of=perf_1.4.ll
ldc2-1.6.0-win64-msvc\bin\ldc2 -release -output-ll perf.d -of=perf_1.6.ll
<compare files perf_1.4.ll and perf_1.6.ll>
```
```On Monday, 27 November 2017 at 10:41:44 UTC, Igor Shirkalin wrote:
> Hello!
>
> I have found that LDC1.5-1.6 generate unoptimized code in contrast to LDC1.3-1.4 in some cases. I tried to extract the example and make it as short as possible. The goal is to get the compiled code with avx(2) instructions.

This will need a lot more investigation to figure out what is going wrong. It could be that the optimization pipeline set up by LDC needs to be adjusted for newer LLVM versions, or that extra annotations are needed.
Some notes:
- It's strange that adding the calculation of `sum` leads to an overall more optimized output with AVX2 instructions (good that you found out about that!).
- It would help if you find a C/C++ equivalent to show the problem to LLVM devs (gcc.godbolt.org has all relevant LLVM/Clang versions)
- The optimization is fragile also in LDC 1.4: manual unrolling of the inner loop somehow removes the AVX2 optimizations. https://godbolt.org/g/NF3eHf  Did I make a mistake?

-Johan

```
```On Thursday, 30 November 2017 at 08:56:31 UTC, Johan Engelen wrote:
> On Monday, 27 November 2017 at 10:41:44 UTC, Igor Shirkalin This will need a lot more investigation to figure out what is going wrong. It could be that the optimization pipeline set up by LDC needs to be adjusted for newer LLVM versions, or that extra annotations are needed.

I'm almost sure that the problem is in new LLVM.

> Some notes:

> - It's strange that adding the calculation of `sum` leads to an overall more optimized output with AVX2 instructions (good that you found out about that!).

> - It would help if you find a C/C++ equivalent to show the problem to LLVM devs (gcc.godbolt.org has all relevant LLVM/Clang versions)

Yes, I have found it for clang: https://bugs.llvm.org/show_bug.cgi?id=35448

> - The optimization is fragile also in LDC 1.4: manual unrolling of the inner loop somehow removes the AVX2 optimizations. https://godbolt.org/g/NF3eHf  Did I make a mistake?

I've noticed that manual unrolling usually doesnt't help to vectorize the code.

> -Johan

```
```On Monday, 27 November 2017 at 13:21:04 UTC, kinke wrote:
> On Monday, 27 November 2017 at 10:41:44 UTC, Igor Shirkalin wrote:
>> Hello!
>>
>> I have found that LDC1.5-1.6 generate unoptimized code in contrast to LDC1.3-1.4 in some cases. I tried to extract the example and make it as short as possible. The goal is to get the compiled code with avx(2) instructions.
>
> LDC 1.5 and 1.6 both come with LLVM 5.0.0, so it looks as if this is an LLVM regression.
> This can be shown by compiling to unoptimized textual LLVM IR (that's the LLVM IR LDC generates, before LLVM optimizations) and comparing it across LDC versions. I did that for LDC 1.4 and 1.6, and the relevant IR is identical:
>
> ldc2-1.4.0-win64-msvc\bin\ldc2 -release -output-ll perf.d -of=perf_1.4.ll
> ldc2-1.6.0-win64-msvc\bin\ldc2 -release -output-ll perf.d -of=perf_1.6.ll
> <compare files perf_1.4.ll and perf_1.6.ll>

It's now obvious the reason of this regression is LLVM 5.0.0
Does it mean it's not time to move to latest LLVM for the latest LDC?

```
```On Thursday, 30 November 2017 at 15:25:31 UTC, Igor Shirkalin wrote:
> It's now obvious the reason of this regression is LLVM 5.0.0
> Does it mean it's not time to move to latest LLVM for the latest LDC?

5.0.0 *is* the latest released version. 5.0.1 is about to be released these days, but whether it'll fix this issue is uncertain. As is whether it's fixed in current LLVM master (6.0.0). LLVM is a huge piece of software, bugs and regressions are to be expected.
```
```On Thursday, 30 November 2017 at 16:01:19 UTC, kinke wrote:
> On Thursday, 30 November 2017 at 15:25:31 UTC, Igor Shirkalin wrote:
>> It's now obvious the reason of this regression is LLVM 5.0.0
>> Does it mean it's not time to move to latest LLVM for the latest LDC?
>
> 5.0.0 *is* the latest released version. 5.0.1 is about to be released these days, but whether it'll fix this issue is uncertain. As is whether it's fixed in current LLVM master (6.0.0). LLVM is a huge piece of software, bugs and regressions are to be expected.

I too read it the way you did, that llvm needs to be updated forward, but I think he meant ldc should stick with 4.0.1 for now.
```
```On Thursday, 30 November 2017 at 22:58:10 UTC, Joakim wrote:
> On Thursday, 30 November 2017 at 16:01:19 UTC, kinke wrote:
>> On Thursday, 30 November 2017 at 15:25:31 UTC, Igor Shirkalin wrote:
>>> It's now obvious the reason of this regression is LLVM 5.0.0
>>> Does it mean it's not time to move to latest LLVM for the latest LDC?
>>
>> 5.0.0 *is* the latest released version. 5.0.1 is about to be released these days, but whether it'll fix this issue is uncertain. As is whether it's fixed in current LLVM master (6.0.0). LLVM is a huge piece of software, bugs and regressions are to be expected.
>
> I too read it the way you did, that llvm needs to be updated forward, but I think he meant ldc should stick with 4.0.1 for now.

Right. Exactly what I meant. Excuse for some irrational English.

```
```On Friday, 1 December 2017 at 04:30:52 UTC, Igor Shirkalin wrote:
> On Thursday, 30 November 2017 at 22:58:10 UTC, Joakim wrote:
>> On Thursday, 30 November 2017 at 16:01:19 UTC, kinke wrote:
>>> On Thursday, 30 November 2017 at 15:25:31 UTC, Igor Shirkalin wrote:
>>>> It's now obvious the reason of this regression is LLVM 5.0.0
>>>> Does it mean it's not time to move to latest LLVM for the latest LDC?
>>>
>>> 5.0.0 *is* the latest released version. 5.0.1 is about to be released these days, but whether it'll fix this issue is uncertain. As is whether it's fixed in current LLVM master (6.0.0). LLVM is a huge piece of software, bugs and regressions are to be expected.
>>
>> I too read it the way you did, that llvm needs to be updated forward, but I think he meant ldc should stick with 4.0.1 for now.
>
> Right. Exactly what I meant. Excuse for some irrational English.

No worries. One performance regression is by no means enough to convince me to step back, especially since anyone is free to compile LDC himself and use LLVM versions as old as 3.7 if they like.
```