वेक्टरनाइज़ेशन और लूप आकार

Question

के संबंध में जीसीसी व्यवहार को परेशान करना प्रारंभ में #pragma omp simd निर्देश के प्रभाव की जांच कर रहा है, मैं एक ऐसे व्यवहार में आया जो मैं व्याख्या नहीं कर सकता, लूप के लिए सरल के वेक्टरलाइजेशन से संबंधित। निम्नलिखित कोड नमूना का परीक्षण इस भयानक compiler explorer पर किया जा सकता है, बशर्ते -O3 निर्देश लागू किया गया है और हम x86 आर्किटेक्चर पर हैं।

क्या कोई मुझे निम्नलिखित अवलोकनों के पीछे तर्क समझा सकता है?

#include <stdint.h> 

void test(uint8_t* out, uint8_t const* in, uint32_t length) 
{ 
    unsigned const l1 = (length * 32)/32; // This is vectorized 
    unsigned const l2 = (length/32)*32; // This is not vectorized 

    unsigned const l3 = (length << 5)>>5; // This is vectorized 
    unsigned const l4 = (length >> 5)<<5; // This is not vectorized 

    unsigned const l5 = length -length%32; // This is not vectorized 
    unsigned const l6 = length & ~(32 -1); // This is not vectorized 

    for (unsigned i = 0; i<l1 /*pick your choice*/; ++i) 
    { 
     out[i] = in[i*2]; 
    } 
} 

मुझे क्या पहेली है कि दोनों एल 1 और एल 3 beeing 32. के गुणकों और लेंथ नहीं vectorized कोड का उत्पादन करते हैं सब के सब होने की गारंटी नहीं के बावजूद vectorized कोड उत्पन्न है, लेकिन 32 के गुणकों होना चाहिए क्या इसके पीछे कोई कारण है?

एक तरफ, #pragma omp simd निर्देश का उपयोग वास्तव में कुछ भी नहीं बदलता है।

संपादित करें: आगे की जांच पड़ताल करने के बाद, व्यवहार के अंतर गायब हो जाता है जब सूचकांक प्रकार size_t है (और कोई सीमा हेरफेर भी जरूरत है), जिसका अर्थ है कि इस vectorized कोड उत्पन्न करता है: अगर किसी को पता है क्यों

#include <stdint.h> 
#include <string> 

void test(uint8_t* out, uint8_t const* in, size_t length) 
{ 
    for (size_t i = 0; i<length; ++i) 
    { 
     out[i] = in[i*2]; 
    } 
} 

लूप वेक्टरिंग इंडेक्स प्रकार पर इतना निर्भर है, तो मुझे और जानना उत्सुक होगा!

EDIT2, मार्क Lakata करने के लिए धन्यवाद, ओ 3 वास्तव में जरूरत है

Answer 1

मुद्दा सरणी सूचकांक में size_t को unsigned से स्पष्ट रूपांतरण है: in[i*2];

आप l1 या l3 तो गणना का उपयोग करते हैं i*2 का size_t प्रकार में हमेशा फिट होगा। इसका अर्थ यह है कि प्रकार unsigned व्यावहारिक रूप से व्यवहार करता है जैसे कि यह size_t था।

लेकिन जब आप अन्य विकल्पों का उपयोग करते हैं, तो गणना i*2 का परिणाम संभवतः size_t में फिट नहीं हो सकता है क्योंकि मान लपेट सकता है और रूपांतरण किया जाना चाहिए।

अगर आप पहला उदाहरण लेते, विकल्प चुनने नहीं एल 1 या L3, और कलाकारों कार्य करें:

out[i] = in[(size_t)i*2]; 

संकलक का अनुकूलन, अगर आप पूरे अभिव्यक्ति डाली:

out[i] = in[(size_t)(i*2)]; 

ऐसा नहीं 'टी।

---

स्टैंडर्ड वास्तव में निर्दिष्ट नहीं है कि सूचकांक में प्रकार size_t होना चाहिए, लेकिन यह संकलक के नजरिए से एक तार्किक कदम है।

Answer 2

मुझे विश्वास है कि आप वेक्टरेशन के साथ अनुकूलन को भ्रमित कर रहे हैं। मैंने आपके compiler explorer और x86 के लिए सेट-ओ 2 का उपयोग किया, और इनमें से कोई भी उदाहरण "वेक्टरकृत" नहीं है।

यहाँ l1

test(unsigned char*, unsigned char const*, unsigned int): 
     xorl %eax, %eax 
     andl $134217727, %edx 
     je  .L1 
.L5: 
     movzbl (%rsi,%rax,2), %ecx 
     movb %cl, (%rdi,%rax) 
     addq $1, %rax 
     cmpl %eax, %edx 
     ja  .L5 
.L1: 
     rep ret 

यहाँ है l2

test(unsigned char*, unsigned char const*, unsigned int): 
     andl $-32, %edx 
     je  .L1 
     leal -1(%rdx), %eax 
     leaq 1(%rdi,%rax), %rcx 
     xorl %eax, %eax 
.L4: 
     movl %eax, %edx 
     addq $1, %rdi 
     addl $2, %eax 
     movzbl (%rsi,%rdx), %edx 
     movb %dl, -1(%rdi) 
     cmpq %rcx, %rdi 
     jne  .L4 
.L1: 
     rep ret 

आश्चर्य की बात नहीं है यही कारण है, क्योंकि तुम क्या कर रहे अनिवार्य रूप से, एक "इकट्ठा" लोड ऑपरेशन है जहां लोड सूचकांक नहीं हैं स्टोर सूचकांक के समान। इकट्ठा/स्कैटर के लिए x86 में कोई समर्थन नहीं है। यह केवल AVX2 और AVX512 में पेश किया गया है, और यह चयनित नहीं है।

थोड़ा लंबा कोड हस्ताक्षरित/हस्ताक्षरित मुद्दों से निपट रहा है, लेकिन कोई वेक्टरेशन चालू नहीं है।