Files that changed from the base of the PR and between 94aacd8 and 05a920f.

• CMakeLists.txt (1 hunks)
• arch/x86/Makefile.in (3 hunks)
• arch/x86/avx2_tables.h (1 hunks)
• arch/x86/chunkset_avx2.c (1 hunks)
• arch/x86/chunkset_avx512.c (1 hunks)
• arch/x86/x86_features.c (2 hunks)
• arch/x86/x86_features.h (1 hunks)
• arch/x86/x86_functions.h (2 hunks)
• chunkset_tpl.h (8 hunks)
• cmake/detect-intrinsics.cmake (2 hunks)
• configure (2 hunks)
• functable.c (1 hunks)
• inffast_tpl.h (1 hunks)

arch/x86/avx2_tables.h (2)

1-5: LGTM: Header structure is well-organized

The header guards and include directive are properly structured.

---

8-38: Verify table pattern correctness

The table shows systematic patterns in offset calculations and remainder values. Let's verify the implementation:

✅ Verification successful

Let me analyze the table pattern and verification results:

1. The table perm_idx_lut shows a systematic pattern:

   • First section (indices 3-15): Uses multiples of 32 (0-10 * 32)
   • Second section (indices 17-31): Uses base offset of 11*32 plus multiples of 16
   • The remainder values follow a logical decreasing pattern

2. The search results show:

   • This is the only instance of perm_idx_lut in the codebase
   • The constants 32 and 16 are used extensively in AVX2/AVX512 SIMD operations
   • This table appears to be part of AVX2-specific optimizations

Let me verify the usage context:

---

Let me check the broader context and usage of this table:

---

Let me check the content of the chunk permute table and related files:

---

Table pattern is correct and consistent with the implementation

The table pattern in perm_idx_lut is verified to be correct based on the following evidence:

1. The table is used in conjunction with permute_table from chunk_permute_table.h for AVX2-specific optimizations
2. The pattern follows the documented structure in chunk_permute_table.h:
   • First section (indices 3-15) uses 32-byte aligned offsets for AVX2 vector operations
   • Second section (indices 17-31) uses 16-byte offsets after the base offset of 11*32 to handle cross-lane permutations
3. The remainder values are correctly decreasing to handle the edge cases as documented
4. The implementation is consistent with the SSSE3 version in chunkset_ssse3.c which uses a similar but smaller table structure

The table's pattern is mathematically sound and properly aligned for AVX2 SIMD operations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if this table is referenced correctly and if similar patterns exist elsewhere

# Look for other permutation tables and their usage
rg -A 2 "static const lut_rem_pair" --type cpp

# Find references to this table
rg "perm_idx_lut" --type cpp

# Look for related constants (32 and 16 multipliers)
rg "32[^0-9]|16[^0-9]" --type cpp arch/x86/

Length of output: 22946

---

Script:

#!/bin/bash
# Find where this table is used
rg -B 5 -A 5 "perm_idx_lut" --type cpp

# Look for related AVX2 permutation functions
rg "perm.*avx2" --type cpp

Length of output: 802

---

Script:

#!/bin/bash
# Look for the chunk permute table header that's included
rg -l "chunk_permute_table.h"

# Check the content of the chunk permute table header
cat ../generic/chunk_permute_table.h

# Look for any AVX2-specific permutation functions
rg -B 3 -A 3 "permute.*avx2|avx2.*permute" --type cpp

Length of output: 317

---

Script:

#!/bin/bash
# Check the content of chunk_permute_table.h from the repository root
cat arch/generic/chunk_permute_table.h

# Look for files that use this table
rg -B 5 -A 5 "lut_rem_pair" --type cpp

# Check the chunkset implementation that might use this table
cat arch/x86/chunkset_ssse3.c

Length of output: 7574

arch/x86/x86_features.c (2)

100-101: LGTM! BMI2 detection implementation is correct.

The BMI2 feature bit (bit 3 in ebx) is correctly checked from CPUID leaf 7, which aligns with Intel's documentation and will properly detect the presence of BMI2 instructions needed for optimized masked operations.

Let's verify the BMI2 detection works as expected:

✅ Verification successful

Based on the results, I can now generate the final response:

BMI2 detection implementation needs attention - potential inconsistency with AVX512 requirements

The verification revealed that BMI2 is not just used for optional optimizations, but is actually a required feature for AVX512_common support:

• In arch/x86/x86_features.c, BMI2 is part of the mandatory requirements: features->has_avx512_common = ... && features->has_bmi2
• However, there's no documentation or clear rationale explaining why BMI2 is a mandatory requirement for AVX512_common

This requirement seems unusual since BMI2 is typically not a prerequisite for AVX512 operations. Let's verify this further:

---

BMI2 requirement for AVX512_common is intentional and correct

The verification reveals that BMI2 is correctly required as part of AVX512_common for this codebase:

1. The configure script and CMake files consistently include BMI2 with AVX512 flags:

   • avx512flag="-mavx512f -mavx512dq -mavx512bw -mavx512vl -mbmi2"
   • This is applied across all build systems (Makefile.in, CMakeLists.txt)

2. The requirement is used in specific optimized implementations:

   • adler32_avx512 and related functions
   • chunkset_avx512 for memory operations
   • vpclmulqdq operations that depend on AVX512_common

3. The BMI2 requirement is part of the architectural design, as evidenced by the compiler flags and feature detection logic working together to ensure optimal performance for the AVX512 implementations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify BMI2 detection is properly used in the codebase
# Test 1: Check if BMI2 detection is consistently implemented across the codebase
rg -A 2 -B 2 "has_bmi2"

# Test 2: Look for BMI2-specific instructions that might be used
ast-grep --pattern 'asm {
  $$$
  pext
  $$$
}'

Length of output: 975

---

Script:

#!/bin/bash
# Check for any documentation or comments explaining the BMI2 requirement
rg -B 5 "avx512.*common" 

# Look for actual AVX512 instruction usage that might depend on BMI2
rg "avx512" -A 2 -B 2

Length of output: 33239

---

113-113: Verify the requirement of BMI2 for AVX512 common features.

Adding BMI2 as a requirement for AVX512 common features is a significant change that could potentially disable AVX512 optimizations on some processors. While this aligns with the PR's goal of optimizing masked operations, please confirm:

1. Are there target processors that support AVX512 but not BMI2?
2. Is disabling AVX512 features on such processors (if they exist) an acceptable trade-off?

Let's check the processor support matrix:

✅ Verification successful

Based on the code analysis, I can now provide a definitive response about the BMI2 requirement for AVX512.

BMI2 requirement for AVX512 is correct and intentional

The requirement of BMI2 for AVX512 features is correct because:

1. BMI2 instructions are essential for optimal performance of AVX512 masked operations, as they provide efficient bit manipulation capabilities needed by the AVX512 implementation.

2. All modern processors that support the full AVX512 feature set (F,DQ,BW,VL) also support BMI2:

   • The code checks for has_avx512_common = has_avx512f && has_avx512dq && has_avx512bw && has_avx512vl && has_bmi2
   • This combination is standard on Intel processors starting from Skylake-X/Skylake-SP, which all include BMI2

3. The codebase has optimized implementations that leverage both AVX512 and BMI2 instructions together, as seen in the compilation flags and feature detection code.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for processor compatibility information in documentation
# Test 1: Look for processor support documentation
fd -g "*.md" -g "*.txt" -X rg -i "processor.*(support|compat)"

# Test 2: Check if there are any existing CPU detection tests
fd -g "*test*.c" -X rg "avx512.*bmi2"

Length of output: 197

---

Script:

#!/bin/bash
# Let's try a different approach to find relevant information

# Search for CPU feature detection and requirements
rg -A 5 -B 5 "has_avx512" 

# Look for any documentation about CPU features
fd "README|CONTRIBUTING|docs" -e md -e txt -X cat

# Search for test files or documentation containing AVX512 or BMI2
rg -i "avx512|bmi2" 

Length of output: 60852

arch/x86/chunkset_avx2.c (1)

7-7: Verify table definitions in avx2_tables.h

The switch from chunk_permute_table.h to avx2_tables.h suggests a reorganization of lookup tables. Please ensure that:

1. All required tables (perm_idx_lut, permute_table, half_rem_vals) are properly defined in the new header
2. The table definitions are equivalent to maintain correctness

✅ Verification successful

Header change is correctly implemented and maintains compatibility

The switch from directly including chunk_permute_table.h to using avx2_tables.h is a well-structured change that:

1. Maintains all required functionality by including the generic chunk_permute_table.h which contains the shared permutation table
2. Properly defines AVX2-specific lookup tables (perm_idx_lut and half_rem_vals) with correct values
3. Organizes the code better by separating architecture-specific tables while reusing common tables

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the table definitions in the new header

# Check if the required tables are defined in avx2_tables.h
rg -A 5 "perm_idx_lut|permute_table|half_rem_vals" "arch/x86/avx2_tables.h"

# Compare with old definitions
rg -A 5 "perm_idx_lut|permute_table|half_rem_vals" "arch/x86/generic/chunk_permute_table.h"

Length of output: 827

---

Script:

#!/bin/bash
# Let's verify the content and structure of both files

# First, check if the old file exists in a different location
fd "chunk_permute_table.h"

# Then get the content of avx2_tables.h to understand its complete structure
cat "arch/x86/avx2_tables.h"

# Also search for any references to these tables in the codebase
rg -A 2 "perm_idx_lut|half_rem_vals" --type c

Length of output: 4091

---

Script:

#!/bin/bash
# Let's check the content of the generic chunk_permute_table.h to complete our verification
cat "arch/generic/chunk_permute_table.h"

Length of output: 3452

arch/x86/Makefile.in (2)

11-12: LGTM: Addition of BMI2 support enhances AVX512 capabilities.

The addition of -mbmi2 to both AVX512FLAG and AVX512VNNIFLAG is appropriate for supporting efficient bit manipulation operations, which aligns well with the PR's goal of optimizing masked moves in the inflate operation.

---

34-34: LGTM: New AVX512 build targets follow consistent patterns.

The addition of chunkset_avx512.o and chunkset_avx512.lo targets maintains consistency with existing AVX targets and correctly applies the necessary compilation flags including NOLTOFLAG for optimization.

Let's verify the consistency of the new targets with existing ones:

Also applies to: 56-61

✅ Verification successful

Verified: AVX512 build targets follow consistent patterns with proper flags

The verification confirms that:

• The new chunkset_avx512 targets use the same flag patterns as other AVX512 implementations (adler32_avx512, crc32_vpclmulqdq)
• All chunkset implementations (SSE2, SSSE3, AVX2, AVX512) consistently use NOLTOFLAG
• Both object (.o) and PIC (.lo) targets are properly defined with appropriate flags

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that all AVX512 targets follow consistent patterns
# Test: Check for consistent flag usage across AVX512 targets
rg "AVX512FLAG.*-c.*\.c$" arch/x86/Makefile.in

# Test: Verify NOLTOFLAG is used consistently
rg "NOLTOFLAG.*chunkset.*\.c$" arch/x86/Makefile.in

Length of output: 1484

arch/x86/x86_functions.h (1)

49-51: LGTM! Function declarations follow established patterns.

The new AVX512 function declarations maintain consistency with existing SSE2/AVX2 implementations while preserving the safety-conscious naming convention (e.g., chunkmemset_safe_avx512).

Let's verify the implementation maintains the safety guarantees:

✅ Verification successful

Let's first locate the implementation files before diving into the specific function details.

---

Function declarations are consistent and implementation maintains safety guarantees

The verification confirms that the AVX512 implementation:

• Uses masked operations (_mm256_mask_storeu_epi8, _mm_maskz_loadu_epi8) for bounds checking
• Implements proper mask generation functions (gen_mask, gen_half_mask) using _bzhi_u32
• Follows the template-based implementation pattern with chunkset_tpl.h

The implementation aligns with the PR objectives of using masked moves for safety and optimizing AVX512 operations while maintaining proper bounds checking.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the AVX512 implementation maintains bounds checking
# Look for bounds checking in the implementation file

# Search for bounds checking patterns in the implementation
rg -A 5 "chunkmemset_safe_avx512.*\{" 

Length of output: 39

---

Script:

#!/bin/bash
# Let's try a broader search to locate the AVX512 implementation files
fd -e c -e cpp -e h "avx512" --exec rg -l "chunkmemset_safe_avx512"

# Also search for any AVX512-related files to understand the implementation structure
fd "avx512|AVX512"

Length of output: 227

---

Script:

#!/bin/bash
# Now that we found the implementation file, let's examine the chunkmemset_safe_avx512 function
# Looking for bounds checking and safety measures
rg -A 15 "chunkmemset_safe_avx512" arch/x86/chunkset_avx512.c

# Also check for any mask-related operations as mentioned in PR objectives
rg "mask|_mm512_mask" arch/x86/chunkset_avx512.c

Length of output: 1363

chunkset_tpl.h (5)

90-90: LGTM: Improved conditional compilation guard.

The additional check !defined(HAVE_HALFCHUNKCOPY) prevents potential conflicts with architecture-specific implementations.

---

167-168: LGTM: Improved remainder handling with masked writes.

The changes properly track length after halfchunk operations and optimize remainder handling using masked writes when available.

Also applies to: 222-226

---

Line range hint 251-261: LGTM: Added fallback for non-masked write architectures.

The implementation safely handles small lengths when masked writes aren't available, maintaining proper alignment requirements.

---

128-136: LGTM: Added masked write optimization for small copies.

The implementation correctly handles the edge case of reading ahead in the buffer while maintaining safety. For small lengths (≤ chunk_t), it efficiently falls back to CHUNKCOPY.

Let's verify the masked write implementation across the codebase:

#!/bin/bash
# Description: Check for consistent masked write handling
# Look for other instances where HAVE_MASKED_READWRITE is used
rg "HAVE_MASKED_READWRITE" -B 2 -A 2

# Look for potential masked write operations
ast-grep --pattern 'storechunk_mask($_, $_, $_)'

---

Line range hint 269-289: Consider potential length truncation in CHUNKCOPY_SAFE.

While changing len to uint64_t improves length handling, casting it to unsigned in the CHUNKMEMSET call could potentially truncate large values. Consider handling this case explicitly.

Let's verify the maximum possible length:

Consider applying this change:

-    return CHUNKMEMSET(out, from, (unsigned)len);
+    if (len > UINT_MAX) {
+        /* Handle large lengths in chunks */
+        while (len > UINT_MAX) {
+            out = CHUNKMEMSET(out, from, UINT_MAX);
+            from += UINT_MAX;
+            len -= UINT_MAX;
+        }
+    }
+    return CHUNKMEMSET(out, from, (unsigned)len);

functable.c (1)

132-132: LGTM! The AVX512 inflate implementation is properly integrated.

The assignment follows the correct pattern and is properly guarded by the AVX512 feature check. The implementation maintains thread safety through atomic assignment and memory barriers.

Let's verify the AVX512 implementation is properly declared:

✅ Verification successful

Let me verify the declaration and consistency of the AVX512 implementation with one more check:

---

AVX512 implementation is properly integrated and declared

The verification confirms:

• inflate_fast_avx512 is correctly declared in arch/x86/x86_functions.h
• The implementation follows the template pattern in arch/x86/chunkset_avx512.c
• The feature detection using has_avx512_common is consistent with other AVX512 optimizations
• The function assignment is placed in the correct AVX512 conditional block alongside other AVX512 functions

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify inflate_fast_avx512 is properly declared and consistent with other AVX512 functions

# Test 1: Check if inflate_fast_avx512 is declared in header files
rg -l "inflate_fast_avx512"

# Test 2: Verify consistent AVX512 feature detection usage
rg "has_avx512" -A 2 -B 2

Length of output: 5127

---

Script:

#!/bin/bash
# Check the declaration and implementation of inflate_fast_avx512
rg "inflate_fast_avx512" -A 2 -B 2

Length of output: 1173

cmake/detect-intrinsics.cmake (1)

79-79: LGTM! Adding BMI2 support enhances AVX512 optimizations.

The addition of -mbmi2 flag to AVX512 and AVX512VNNI configurations is a good improvement. BMI2 instructions complement AVX512 masked operations, potentially improving the performance of bit manipulation tasks.

Let's verify that the compiler correctly detects and enables these features:

Also applies to: 86-86, 117-117, 122-122

✅ Verification successful

Let me gather more information about the AVX512 and BMI2 usage in the codebase to ensure there are no conflicts or missing configurations.

---

Based on the gathered information, I can now provide a final response:

BMI2 flag addition is correctly integrated with AVX512 optimizations

The addition of -mbmi2 flag is well-justified and properly implemented:

• BMI2 instructions (_bzhi_u32) are actively used in arch/x86/chunkset_avx512.c
• The runtime feature detection in arch/x86/x86_features.c correctly checks for BMI2 support
• The flag is consistently added to both AVX512 and AVX512VNNI configurations across all supported compilers

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that both AVX512 and BMI2 instructions are detected
# Expected: The compiler should recognize both instruction sets

# Test 1: Check if compiler accepts the combined flags
echo '#include <immintrin.h>' > test.c
echo 'int main() { return 0; }' >> test.c

for CC in gcc clang icc; do
    if command -v $CC >/dev/null 2>&1; then
        echo "Testing $CC..."
        $CC -mavx512f -mavx512dq -mavx512bw -mavx512vl -mbmi2 -c test.c 2>&1 || echo "$CC: Failed to compile with AVX512+BMI2"
    fi
done

# Test 2: Search for other AVX512 configurations that might need BMI2
rg -l "mavx512" --type cmake

Length of output: 255

---

Script:

#!/bin/bash
# Check the complete context of AVX512 and BMI2 usage in detect-intrinsics.cmake
cat cmake/detect-intrinsics.cmake

# Search for any BMI2-specific checks or configurations
rg "bmi2" -i --type cmake

# Look for any assembly or intrinsics usage of BMI2 instructions
rg "bmi2|_pext_|_pdep_|_bzhi_|_mulx_" -i

Length of output: 22861

CMakeLists.txt (1)

984-985: LGTM! The AVX512 chunkset integration looks good.

The addition of chunkset_avx512.c and its feature info message follows the established pattern for AVX512 optimizations in the build system.

Let's verify the AVX512 flag propagation:

✅ Verification successful

AVX512 chunkset compilation flags are properly set

The verification confirms that chunkset_avx512.c is correctly added to AVX512_SRCS and all AVX512 sources are compiled with the appropriate flags:

• The file is added to AVX512_SRCS list
• All AVX512_SRCS are compiled with ${AVX512FLAG} ${NOLTOFLAG}
• The feature info message correctly references the AVX512FLAG variable

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify AVX512 flags are properly set for chunkset_avx512.c
# Test: Check if chunkset_avx512.c is compiled with AVX512 flags
rg -l "set_property.*SOURCE.*chunkset_avx512.c.*PROPERTY.*COMPILE_FLAGS.*AVX512FLAG"

Length of output: 86

---

Script:

#!/bin/bash
# Let's check the CMakeLists.txt more thoroughly for AVX512 flag settings
rg -A 5 "AVX512_SRCS.*chunkset_avx512" CMakeLists.txt

# Also check for any general AVX512 compilation flag settings
rg "set_property.*COMPILE_FLAGS.*AVX512" CMakeLists.txt

# And check for any other AVX512 source file compilations for reference
rg "set_property.*SOURCE.*avx512.*COMPILE_FLAGS" CMakeLists.txt

Length of output: 971

configure (2)

1592-1593: LGTM: Architecture-specific objects properly configured.

The addition of chunkset_avx512.o and chunkset_avx512.lo to the architecture-specific objects list is correct. This ensures the new AVX512-optimized implementation is included in both static and shared library builds.

---

109-109: Verify BMI2 instruction set availability.

The addition of -mbmi2 to AVX512 flags suggests that the new implementation relies on BMI2 instructions for efficient bit manipulation. This is aligned with the PR's goal of optimizing masked writes. However, we should ensure proper runtime detection of BMI2 support.

✅ Verification successful

Based on the results, I can now generate the final response as we have sufficient information about BMI2 detection in the codebase.

BMI2 detection is properly implemented alongside AVX512 features

The codebase correctly handles BMI2 detection:

• Runtime detection is implemented in arch/x86/x86_features.c through CPU feature flags
• BMI2 is checked as a requirement alongside AVX512 features
• The compiler flags in both configure and arch/x86/Makefile.in consistently include -mbmi2 with AVX512 flags

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if BMI2 detection is properly implemented in the codebase

# Test: Look for BMI2 feature detection in x86 feature detection code
rg -A 5 "BMI2|bmi2" arch/x86/

Length of output: 1280

arch/x86/chunkset_avx512.c (1)

185-189: Verify macro definitions for AVX512 compatibility

Ensure that the macros CHUNKSIZE, CHUNKUNROLL, CHUNKMEMSET, and related definitions are correctly set for AVX512 operations. This is crucial for maintaining consistency and performance optimizations specific to the AVX512 architecture.

Run the following command to check the macro definitions:

✅ Verification successful

AVX512 chunk operations are correctly defined and integrated

The macro definitions in chunkset_avx512.c are properly set up and integrated with the template implementation. The verification shows:

1. The macros correctly map to AVX512-specific functions
2. The template file (chunkset_tpl.h) provides the core implementation that these macros hook into
3. The functions are properly declared in x86_functions.h and are enabled when AVX512 features are available
4. The implementation follows the same pattern as other SIMD variants (SSE2, SSSE3, AVX2)

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that AVX512-specific macros are correctly defined.

# Expected: Macros should be defined with AVX512-specific values.
grep -E '#define CHUNKSIZE|#define CHUNKUNROLL' chunkset_tpl.h

Length of output: 64

---

Script:

#!/bin/bash
# Let's search for these macro definitions in the entire codebase
rg -l "CHUNKSIZE|CHUNKUNROLL|CHUNKMEMSET" arch/x86/

# Then examine the content of relevant files
find arch/x86/ -type f -name "*.h" -o -name "*.c" | xargs grep -l "CHUNKSIZE\|CHUNKUNROLL\|CHUNKMEMSET" | while read -r file; do
    echo "=== $file ==="
    cat "$file" | grep -A 2 -B 2 "CHUNKSIZE\|CHUNKUNROLL\|CHUNKMEMSET"
done

Length of output: 2671

---

Script:

#!/bin/bash
# Let's examine the template file that's included and the actual implementations
echo "=== Content of chunkset_tpl.h ==="
cat arch/x86/chunkset_tpl.h

echo -e "\n=== AVX512 Implementation Details ==="
# Look for the actual implementation of these functions in AVX512
rg -A 5 "chunksize_avx512|chunkunroll_avx512|chunkmemset_avx512" arch/x86/chunkset_avx512.c

Length of output: 599

---

Script:

#!/bin/bash
# Let's check if the template file might be in a different location
fd -t f "chunkset_tpl.h"

# Also let's look for the actual implementations of these functions
echo "=== Function Implementations ==="
rg -B 3 "^static.*chunk(size|unroll|memset)_avx512" arch/x86/chunkset_avx512.c

# Check if there are any related header files that might contain definitions
echo -e "\n=== Related Headers ==="
fd -e h . | xargs grep -l "chunk.*_avx512"

Length of output: 328

---

Script:

#!/bin/bash
# Let's examine the template file and the header file containing AVX512 definitions
echo "=== Content of chunkset_tpl.h ==="
cat chunkset_tpl.h

echo -e "\n=== Content of x86_functions.h ==="
cat arch/x86/x86_functions.h | grep -A 5 -B 5 "avx512"

# Let's also check if these functions are declared as prototypes
echo -e "\n=== Function Declarations ==="
rg "chunk(size|unroll|memset)_avx512" --type c --type h

Length of output: 12030

Files that changed from the base of the PR and between 05a920f and 375af7f.

• CMakeLists.txt (1 hunks)
• arch/x86/Makefile.in (3 hunks)
• arch/x86/avx2_tables.h (1 hunks)
• arch/x86/chunkset_avx2.c (1 hunks)
• arch/x86/chunkset_avx512.c (1 hunks)
• arch/x86/x86_features.c (2 hunks)
• arch/x86/x86_features.h (1 hunks)
• arch/x86/x86_functions.h (2 hunks)
• chunkset_tpl.h (8 hunks)
• cmake/detect-intrinsics.cmake (2 hunks)
• configure (2 hunks)
• functable.c (1 hunks)
• inffast_tpl.h (1 hunks)

• CMakeLists.txt
• arch/x86/avx2_tables.h
• arch/x86/chunkset_avx2.c
• arch/x86/x86_features.h
• arch/x86/x86_functions.h
• cmake/detect-intrinsics.cmake
• configure
• functable.c
• inffast_tpl.h

arch/x86/x86_features.c (2)

113-113: Verify the BMI2 requirement for AVX512_common features.

Making BMI2 a requirement for has_avx512_common is a significant change that could potentially disable AVX512 optimizations on some processors. While this might be necessary for the masked write optimizations:

1. Could you confirm if there are any AVX512-capable processors that don't support BMI2?
2. Is there a fallback path for processors with AVX512 but without BMI2?

Let's check processor support patterns:

#!/bin/bash
# Search for documentation or comments about processor support requirements
rg -B 5 -A 5 "AVX512.*BMI2|BMI2.*AVX512" --type-add 'docs:*.{txt,md,rst}'

---

100-101: BMI2 feature detection looks correct!

The implementation correctly checks bit 3 of the EBX register from CPUID leaf 7 for BMI2 support, following Intel's documentation.

Let's verify the BMI2 bit position in other x86 feature detection implementations:

✅ Verification successful

BMI2 feature detection implementation is correct

The implementation is verified to be correct based on the following evidence:

• The BMI2 check is properly placed within CPUID leaf 7 block (maxbasic >= 7)
• The bit position 0x8 (bit 3) in ebx register is correct according to Intel's specification for BMI2 detection
• The feature is correctly integrated into the x86_cpu_features structure and properly used as a requirement for AVX512 common features
• The implementation follows the same pattern as other CPU feature detections in the file

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for BMI2 detection patterns in other codebases for verification
rg -i "bmi2.*=.*ebx.*0x8|ebx.*0x8.*bmi2" --type cpp

Length of output: 75

---

Script:

#!/bin/bash
# Let's try a broader search for BMI2 detection patterns
rg -B 5 -A 5 "bmi2" --type cpp

# Also search for CPUID leaf 7 feature detection patterns
rg -B 5 -A 5 "cpuid.*7.*ebx" --type cpp

# Look for x86 feature detection header files
fd -e h "feature|cpu" arch/x86/

Length of output: 684

---

Script:

#!/bin/bash
# Let's examine the x86_features.c file directly to understand the context
cat arch/x86/x86_features.c

# Also look for any BMI2-related constants or defines
rg -B 2 -A 2 "0x8|BMI2" arch/x86/

Length of output: 7031

arch/x86/Makefile.in (3)

11-12: LGTM: Addition of BMI2 support enhances masked operations

The addition of -mbmi2 to AVX512 flags is appropriate as BMI2's bit manipulation instructions (particularly BZHI) complement AVX512's masked operations, which aligns well with the PR's objective of optimizing masked writes.

---

34-34: LGTM: New build targets follow established patterns

The addition of chunkset_avx512 targets maintains consistency with existing build patterns and proper alphabetical ordering.

---

56-61: LGTM: Compilation rules are consistent with existing patterns

The compilation rules for chunkset_avx512 targets are properly structured with correct flags and PIC support.

Let's verify the source file existence and consistency:

✅ Verification successful

Compilation rules for chunkset_avx512 targets are correctly implemented

The verification confirms:

• Source file chunkset_avx512.c exists at the correct location
• Compilation rules follow the same pattern as other architecture-specific chunkset implementations:
  • Uses architecture-specific flags (AVX512FLAG like others use AVX2FLAG, SSE2FLAG, etc.)
  • Includes NOLTOFLAG consistently
  • Adds -DPIC flag for shared library objects (.lo)
  • Maintains consistent variable usage (CC, CFLAGS/SFLAGS, INCLUDES)

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify the chunkset_avx512.c source file exists
fd "chunkset_avx512.c" --type f

# Check if other chunkset implementations follow similar patterns
rg -A 2 "chunkset_.*\.c" --type make

Length of output: 2861

chunkset_tpl.h (4)

Line range hint 90-109: LGTM: Improved conditional compilation directive.

The updated condition defined(HAVE_HALF_CHUNK) && !defined(HAVE_HALFCHUNKCOPY) ensures this implementation is only used when half-chunk operations are supported but no architecture-specific implementation exists.

---

128-136: LGTM: Efficient handling of short forward copies using masked writes.

The optimization correctly handles the case where we're reading from ahead in the buffer by falling back to CHUNKCOPY when the length fits in a single chunk. The comment about compiler optimization of identical code segments is insightful.

---

167-168: LGTM: Proper length tracking after halfchunk store.

The explicit length adjustment and pointer advancement after storing a halfchunk maintains correct state for subsequent operations.

---

222-226: LGTM: Efficient remainder handling using masked writes.

The use of storechunk_mask with a generated mask for remaining bytes is an excellent optimization that:

• Eliminates bounds checking overhead
• Leverages efficient AVX512 masked write operations
• Maintains memory safety without performance penalty

arch/x86/chunkset_avx512.c (7)

36-56: Efficient Implementation of 'chunkmemset' Functions

The chunkmemset_* functions are efficiently implemented using appropriate intrinsic functions, optimizing performance for various data sizes.

---

58-68: Correct Use of Load and Store Operations

The loadchunk, storechunk, and storechunk_mask functions correctly utilize AVX512 intrinsics for loading and storing data, ensuring proper handling of chunked data.

---

70-93: Well-Implemented 'CHUNKCOPY' Function

The CHUNKCOPY function effectively handles copying data chunks, including proper handling of remaining bytes using masked operations. The logic ensures data is copied accurately and efficiently.

---

95-125: Efficient Implementation of 'GET_CHUNK_MAG' Function

The GET_CHUNK_MAG function is effectively implemented, utilizing AVX512 intrinsics and appropriate permutation logic to handle data retrieval based on distance parameters.

---

127-139: Proper Handling in Half-Chunk Functions

The functions loadhalfchunk, storehalfchunk, and halfchunk2whole correctly handle half-chunk data, ensuring proper data manipulation and conversion between half chunks and whole chunks.

---

141-152: Effective Implementation of 'GET_HALFCHUNK_MAG' Function

The GET_HALFCHUNK_MAG function correctly retrieves half-chunk magnitudes using appropriate AVX512 intrinsics and permutation logic, ensuring efficient data handling.

---

154-177: Well-Structured 'HALFCHUNKCOPY' Function

The HALFCHUNKCOPY function efficiently copies half-chunk data, properly managing remaining bytes with masked operations. The implementation is clear and maintains consistency with chunk copying practices.

Line range hint 269-289: Consider potential truncation in CHUNKMEMSET call.

While the change to uint64_t for len parameter improves the supported range, the cast to unsigned when calling CHUNKMEMSET could lead to truncation for values larger than UINT_MAX.

Consider one of these solutions:

-    return CHUNKMEMSET(out, from, (unsigned)len);
+    // Solution 1: Split large copies into chunks
+    while (len > UINT_MAX) {
+        out = CHUNKMEMSET(out, from, UINT_MAX);
+        from += UINT_MAX;
+        len -= UINT_MAX;
+    }
+    return CHUNKMEMSET(out, from, (unsigned)len);

+    // Solution 2: Assert maximum length
+    Assert(len <= UINT_MAX, "Length exceeds maximum supported value");
+    return CHUNKMEMSET(out, from, (unsigned)len);

Files that changed from the base of the PR and between 375af7f and 51e7081.

• CMakeLists.txt (1 hunks)
• arch/x86/Makefile.in (3 hunks)
• arch/x86/avx2_tables.h (1 hunks)
• arch/x86/chunkset_avx2.c (1 hunks)
• arch/x86/chunkset_avx512.c (1 hunks)
• arch/x86/x86_features.c (2 hunks)
• arch/x86/x86_features.h (1 hunks)
• arch/x86/x86_functions.h (2 hunks)
• chunkset_tpl.h (8 hunks)
• cmake/detect-intrinsics.cmake (2 hunks)
• configure (2 hunks)
• functable.c (1 hunks)
• inffast_tpl.h (1 hunks)

• CMakeLists.txt
• arch/x86/Makefile.in
• arch/x86/avx2_tables.h
• arch/x86/chunkset_avx2.c
• arch/x86/x86_features.c
• arch/x86/x86_features.h
• arch/x86/x86_functions.h
• cmake/detect-intrinsics.cmake
• configure
• functable.c
• inffast_tpl.h

Line range hint 269-289: Consider explicit type conversion for len parameter.

The change from unsigned to uint64_t for len improves large buffer support. However, there's an implicit conversion when calling CHUNKMEMSET:

return CHUNKMEMSET(out, from, (unsigned)len);

While this works because we've already bounded len by safelen, consider adding a comment explaining why the conversion is safe here.

28-30: Consider adding function documentation for clarity

To enhance readability and maintainability, consider adding a brief comment explaining the purpose and usage of the gen_half_mask function. This will help other developers understand its role in generating half-width masks.

32-34: Consider adding function documentation for clarity

Similarly, adding a comment to describe the gen_mask function would provide insight into its functionality in generating full-width masks, aiding future code maintenance.

153-176: Add documentation to HALFCHUNKCOPY for better understanding

Including a comment that describes the HALFCHUNKCOPY function will improve code clarity, helping others understand its purpose and how it complements CHUNKCOPY in handling half-size chunks.

Files that changed from the base of the PR and between 375af7f and 767c58a.

• CMakeLists.txt (1 hunks)
• arch/x86/Makefile.in (3 hunks)
• arch/x86/avx2_tables.h (1 hunks)
• arch/x86/chunkset_avx2.c (1 hunks)
• arch/x86/chunkset_avx512.c (1 hunks)
• arch/x86/x86_features.c (2 hunks)
• arch/x86/x86_features.h (1 hunks)
• arch/x86/x86_functions.h (2 hunks)
• chunkset_tpl.h (8 hunks)
• cmake/detect-intrinsics.cmake (2 hunks)
• configure (2 hunks)
• functable.c (1 hunks)
• inffast_tpl.h (1 hunks)

• CMakeLists.txt
• arch/x86/Makefile.in
• arch/x86/avx2_tables.h
• arch/x86/chunkset_avx2.c
• arch/x86/x86_features.c
• arch/x86/x86_features.h
• arch/x86/x86_functions.h
• cmake/detect-intrinsics.cmake
• configure
• functable.c
• inffast_tpl.h

Reviewing files that changed from the base of the PR and between 767c58a and ce5fb26.

• CMakeLists.txt (1 hunks)
• arch/x86/Makefile.in (3 hunks)
• arch/x86/avx2_tables.h (1 hunks)
• arch/x86/chunkset_avx2.c (1 hunks)
• arch/x86/chunkset_avx512.c (1 hunks)
• arch/x86/x86_features.c (2 hunks)
• arch/x86/x86_features.h (1 hunks)
• arch/x86/x86_functions.h (2 hunks)
• chunkset_tpl.h (8 hunks)
• cmake/detect-intrinsics.cmake (2 hunks)
• configure (2 hunks)
• functable.c (1 hunks)
• inffast_tpl.h (1 hunks)

• arch/x86/Makefile.in
• arch/x86/avx2_tables.h
• arch/x86/chunkset_avx2.c
• arch/x86/chunkset_avx512.c
• arch/x86/x86_features.c
• arch/x86/x86_features.h
• arch/x86/x86_functions.h
• cmake/detect-intrinsics.cmake
• configure
• functable.c
• inffast_tpl.h