Skip to content

Codegen weirdness for sum of count_ones over an array #101060

@alion02

Description

@alion02

(Issue loosely owned by @wesleywiser and @pnkfelix monitoring llvm/llvm-project#57476 )

Original Description below

pub fn f(arr: [u64; 2]) -> u32 {
    arr.into_iter().map(u64::count_ones).sum()
}

Before 1.62.0, this code correctly compiled to two popcounts and an addition on a modern x86-64 target.

example::f:
        popcnt  rcx, qword ptr [rdi]
        popcnt  rax, qword ptr [rdi + 8]
        add     eax, ecx
        ret

Since 1.62.0 (up to latest nightly), the codegen is... baffling at best.

.LCPI0_0:
        .zero   16,15
.LCPI0_1:
        .byte   0
        .byte   1
        .byte   1
        .byte   2
        .byte   1
        .byte   2
        .byte   2
        .byte   3
        .byte   1
        .byte   2
        .byte   2
        .byte   3
        .byte   2
        .byte   3
        .byte   3
        .byte   4
example::f:
        sub     rsp, 40
        vmovups xmm0, xmmword ptr [rdi]
        vmovdqa xmm1, xmmword ptr [rip + .LCPI0_0]
        vmovdqa xmm3, xmmword ptr [rip + .LCPI0_1]
        vmovaps xmmword ptr [rsp], xmm0
        vmovdqa xmm0, xmmword ptr [rsp]
        vpand   xmm2, xmm0, xmm1
        vpsrlw  xmm0, xmm0, 4
        vpand   xmm0, xmm0, xmm1
        vpshufb xmm2, xmm3, xmm2
        vpxor   xmm1, xmm1, xmm1
        vpshufb xmm0, xmm3, xmm0
        vpaddb  xmm0, xmm0, xmm2
        vpsadbw xmm0, xmm0, xmm1
        vpshufd xmm1, xmm0, 170
        vpaddd  xmm0, xmm0, xmm1
        vmovd   eax, xmm0
        add     rsp, 40
        ret

The assembly for the original function is now a terribly misguided autovectorization. And, just to make sure (even though it's pretty obvious), I did run a benchmark - the autovectorized function is ~8x slower on my Zen 2 system.

Calling that function from a different function brings back normal assembly. -Cno-vectorize-slp does nothing. I don't know exactly what -Cno-vectorize-loops does, but it's not good.

If you change the length of the array to 4, both functions get autovectorized. -Cno-vectorize-slp fixes the second function now. Adding -Cno-vectorize-loops causes the passthrough function to generate the worst assembly.

Changing into_iter to iter fixes length 2, but doesn't fix length 4.

I could go on, but in short it's a whole mess.

I found a workaround that consistently works for all lengths: iter and -Cno-vectorize-slp.

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged +A-array +A-codegen +A-iterators +A-LLVM +A-simd +I-slow +O-x86_64 +perf-regression

Activity

added
C-bugCategory: This is a bug.
regression-untriagedUntriaged performance or correctness regression.
on Aug 26, 2022
added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
A-arrayArea: `[T; N]`
A-codegenArea: Code generation
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
A-SIMDArea: SIMD (Single Instruction Multiple Data)
I-slowIssue: Problems and improvements with respect to performance of generated code.
O-x86_64Target: x86-64 processors (like x86_64-*) (also known as amd64 and x64)
regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.
and removed
regression-untriagedUntriaged performance or correctness regression.
on Aug 26, 2022
removed
A-SIMDArea: SIMD (Single Instruction Multiple Data)
on Aug 26, 2022

4 remaining items

apiraino

apiraino commented on Aug 31, 2022

@apiraino
Contributor

WG-prioritization assigning priority (Zulip discussion). IIUC this and the related issues seem to be caused by an LLVM regression (see comment).

@rustbot label -I-prioritize +P-high t-compiler

added
P-highHigh priority
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
and removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Aug 31, 2022
nikic

nikic commented on Aug 31, 2022

@nikic
Contributor

Reduced example:

target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i64 @test(ptr %arr) {
entry:
  br label %loop

loop:
  %accum = phi i64 [ %accum.next, %loop ], [ 0, %entry ]
  %iv = phi i64 [ %iv.next, %loop ], [ 0, %entry ]
  %iv.next = add nuw i64 %iv, 1
  %gep = getelementptr inbounds i64, ptr %arr, i64 %iv
  %value = load i64, ptr %gep, align 8
  %ctpop = tail call i64 @llvm.ctpop.i64(i64 %value)
  %accum.next = add i64 %accum, %ctpop
  %exitcond = icmp eq i64 %iv.next, 2
  br i1 %exitcond, label %exit, label %loop

exit:
  %lcssa = phi i64 [ %accum.next, %loop ]
  ret i64 %lcssa
}

declare i64 @llvm.ctpop.i64(i64)

The cost model for znver2 says that ctpop.i64 costs 1 and ctpop.v2i64 costs 3, which is why the vectorization is considered profitable.

nikic

nikic commented on Aug 31, 2022

@nikic
Contributor

Upstream issue: llvm/llvm-project#57476

Alternatively, this would also be fixed if we managed to unroll the loop early (during full unroll rather than runtime unroll). That's probably where the into_iter distinction comes from.

added
WG-noneIndicates that no working group is assigned to an issue, but it *does* have an active owner
on Sep 30, 2022
nikic

nikic commented on Apr 3, 2023

@nikic
Contributor

Still an issue with LLVM 16.

nikic

nikic commented on Aug 14, 2023

@nikic
Contributor

Godbolt: https://godbolt.org/z/MoYTvb9qW

Still an issue with LLVM 17.

added
WG-llvmWorking group: LLVM backend code generation
and removed
WG-noneIndicates that no working group is assigned to an issue, but it *does* have an active owner
on Nov 17, 2023
qarmin

qarmin commented on Dec 27, 2023

@qarmin

Now nightly version(but not stable or beta) produce such output

example::f:
        popcnt  rcx, qword ptr [rdi]
        popcnt  rax, qword ptr [rdi + 8]
        add     eax, ecx
        ret

example::g:
        popcnt  rcx, qword ptr [rdi]
        popcnt  rax, qword ptr [rdi + 8]
        add     eax, ecx
        ret
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-autovectorizationArea: Autovectorization, which can impact perf or code sizeA-codegenArea: Code generationC-bugCategory: This is a bug.I-slowIssue: Problems and improvements with respect to performance of generated code.O-x86_64Target: x86-64 processors (like x86_64-*) (also known as amd64 and x64)P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.WG-llvmWorking group: LLVM backend code generationregression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @pnkfelix@nikic@wesleywiser@the8472@apiraino

        Issue actions

          Codegen weirdness for `sum` of `count_ones` over an array · Issue #101060 · rust-lang/rust