Có vzeroall zero đăng ký ymm16 đến ymm31?

Các tài liệu cho vzeroallxuất hiện không nhất quán. Văn xuôi nói:

Nội dung số không hướng dẫn của tất cả các thanh ghi XMM hoặc YMM.

Tuy nhiên, mã giả bên dưới chỉ ra rằng trong chế độ 64 bit, chỉ các thanh ghi ymm0thông qua ymm15bị ảnh hưởng:

IF (64-bit mode)
    limit ←15
ELSE
    limit ← 7
FOR i in 0 .. limit:
    simd_reg_file[i][MAXVL-1:0] ← 0

Trên AVX-512 Máy hỗ trợ thanh toán bù trừ lên đến ymm15là không giống như thanh toán bù trừ "tất cả" vì ymm16qua ymm31tồn tại.

Là văn xuôi hoặc mã giả chính xác?

— BeeOnRope
nguồn

Theo google, mã giả là chính xác. Chỉ 0-15 bị ảnh hưởng. Việc thực hiện bochs cũng cho biết:// clear only 16 registers even if AVX-512 is present

— Jester

@Jester, hướng dẫn AMD nói tương tự. Có lẽ liên quan đến các bộ xử lý có hỗ trợ AVX512 không còn yêu cầu zero nửa trên của các thanh ghi vì lý do hiệu suất. Sau khi vzeroupper broadwell không cần thiết (bao gồm tất cả các bộ xử lý AVX512). Tôi cho rằng họ đã quyết định không sửa đổi hành vi của vzeroall và vzeroupper vì việc sử dụng các hướng dẫn này không còn cần thiết trên các bộ xử lý này nữa vì vậy chúng chủ yếu là vì lý do di sản.

— Michael Petch

@MichaelPetch: vzeroupper đôi khi vẫn cần thiết trên Skylake; Không sử dụng được có thể làm cho các lệnh SSE bị chậm (phụ thuộc sai): Tại sao mã SSE này chậm hơn 6 lần mà không có VZEROUPPER trên Skylake? . Nhưng làm bẩn ymm / zmm16..31 không thể gây ra vấn đề đó vì chúng không thể truy cập được với SSE cũ. (Và tôi nghĩ rằng đừng tham gia vào các quá trình chuyển đổi trạng thái trên đã lưu mà dường như Ice Lake được giới thiệu lại). Ngoài ra, SKX có hiệu ứng turbo cho zmm bẩn: Tự động xác định nơi thực hiện lệnh AVX-512 lừa đảo

— Peter Cordes

Trong một số cách, hiệu quả của việc không sử dụng vzerouppertrên các CPU mới hơn có thể tồi tệ hơn nhiều do ảnh hưởng của việc hợp nhất các uops và mở rộng ngầm (đó là điều được ám chỉ trong các bình luận mà Peter liên kết).

— BeeOnRope

Sự khác biệt giữa các thanh ghi 0-15 "cao" và "thấp" dường như là như thế này: sự bẩn chỉ xảy ra với các thanh ghi thấp: đặt CPU không phải là trạng thái trên bẩn không xảy ra nếu bạn chỉ ghi các thanh ghi trên . Tuy nhiên, một khi bạn ở trạng thái bẩn, tất cả các thanh ghi đều bị ảnh hưởng, kể cả các thanh ghi trên. Đây là một chút không phù hợp với lý thuyết ban đầu của tôi. Lý thuyết ban đầu của tôi là việc mở rộng ngầm định không (chỉ là?) Hiệu ứng hợp nhất, bởi vì nó đã xảy ra đối với các hướng dẫn AVX được mã hóa VEX không thực hiện bất kỳ sự hợp nhất nào.

— BeeOnRope

Có vẻ như đó là một vấn đề mô tả, nếu bạn nhìn vào SDM mới nhất, bạn sẽ thấy mô tả đó đã được thay đổi gần đây và bây giờ nó nói rằng VZEROALL không thay đổi YMM16 ... YMM31.

— Matt Đột quỵ
nguồn

Cảm ơn! Tôi đã kiểm tra bản sao SDM của mình, cái mà tôi thường giữ cho đến nay, nhưng trong trường hợp này không đủ cập nhật.

— BeeOnRope

Tôi đã googled bit, và tôi nghĩ rằng tôi đã cảm ơn Q của bạn một lỗi trong LLVM khi họ triển khai VZEROALL để hủy bỏ tất cả các thanh ghi YMM bao gồm YMM16 .., YMM31 - list.llvm.org/pipermail/llvm-commits/Week-of-Mon -20170130 / Hoài

— Matt. Stroh

@ Matt.Stroh: sự thay đổi sai đó hoặc không bao giờ được thực hiện hoặc đã được hoàn nguyên. Clang9.0 hiện tại sẽ sử dụng ymm16để lưu __m256xung quanh _mm256_zeroall(): godbolt.org/z/HK7_Xy . Điều đó chỉ có ý nghĩa nếu nó biết rằng zeroall không chạm vào ymm16. clang3.9.1 không tràn vào bộ nhớ nên có thể nó đã có trong phiên bản đó hoặc có thể nó không tối ưu hóa hiệu quả. Hmm, clang (3.9 và hiện tại) không biết rằng a __m128có thể để lại trong xmm0 ngang _mm256_zeroupper(). godbolt.org/z/DwMyMV

— Peter Cordes