Clang में [[trivial_abi]] के बारे में

अंत में, मैंने [[trivial_abi]] के बारे में एक पोस्ट लिखी!

यह क्लैंग ट्रंक में एक नई मालिकाना विशेषता है, फरवरी 2018 तक नया है। यह सी ++ भाषा का एक विक्रेता विस्तार है, यह मानक सी ++ नहीं है, यह जीसीसी ट्रंक द्वारा समर्थित नहीं है, और सीजी मानक में इसे शामिल करने के लिए डब्ल्यूजी 21 के लिए कोई सक्रिय प्रस्ताव नहीं हैं, जहां तक ​​मुझे पता है।



मैंने इस सुविधा के कार्यान्वयन में भाग नहीं लिया। मैं बस cfe-commits मेलिंग सूची पर पैच को देखा और खुद को चुपचाप सराहना की। लेकिन यह इतनी अच्छी सुविधा है कि मुझे लगता है कि हर किसी को इसके बारे में पता होना चाहिए।

इसलिए, पहली चीज जो हम शुरू करेंगे: यह एक मानक विशेषता नहीं है, और क्लैंग ट्रंक इसके लिए [[trivial_abi]] विशेषता की मानक वर्तनी का समर्थन नहीं करता है। इसके बजाय, आपको इसे पुरानी शैली में लिखना चाहिए, जैसा कि नीचे दिखाया गया है:

__attribute__((trivial_abi)) __attribute__((__trivial_abi__)) [[clang::trivial_abi]] 

और, क्योंकि यह एक विशेषता है, संकलक इस बारे में बहुत चुस्त है कि आप इसे कहाँ पेस्ट करते हैं, और यदि आप इसे गलत जगह पर पेस्ट करते हैं तो निष्क्रिय आक्रामक तरीके से चुप रहें (क्योंकि अपरिचित विशेषताओं को केवल संदेशों के बिना अनदेखा किया जाता है)। यह एक बग नहीं है, यह एक विशेषता है। सही सिंटैक्स यह है:

 #define TRIVIAL_ABI __attribute__((trivial_abi)) class TRIVIAL_ABI Widget { // ... }; 

इससे क्या समस्या हल होती है?

04/17/2018 को मेरी पोस्ट याद रखें जहां मैंने कक्षा के दो संस्करण दिखाए थे?

लगभग। perev: चूँकि ०४/१v/२०१ a के पोस्ट की मात्रा थोड़ी है, इसलिए मैंने इसे अलग से प्रकाशित नहीं किया, लेकिन इसे यहीं बिगाड़ने वाले के नीचे डाल दिया।

 struct Foo { int value; ~Foo() = default; // trivial }; struct Bar { int value; ~Bar() {} // deliberately non-trivial }; 

उस पोस्ट में, कोड दिया गया है जिसमें कंपाइलर फू के लिए बार की तुलना में खराब कोड उत्पन्न करता है। यह चर्चा करने योग्य है कि यह अप्रत्याशित क्यों था। प्रोग्रामर सहजता से उम्मीद करते हैं कि "ट्रिवियल" कोड "नैटिवियल" कोड से बेहतर होगा। ज्यादातर स्थितियों में यही होता है। विशेष रूप से, यह मामला है जब हम एक फ़ंक्शन कॉल करते हैं या वापस आते हैं:

 template<class T> T incr(T obj) { obj.value += 1; return obj; } 

incr निम्नलिखित कोड का संकलन करता है:

 leal 1(%rdi), %eax retq 

(leal x86 कमांड का अर्थ है "एड।") हम देखते हैं कि हमारी 4-बाइट obj को% edi रजिस्टर में incr करने के लिए पास किया गया है, और हम इसके मूल्य में 1 जोड़ते हैं और इसे% ex पर लौटाते हैं। इनपुट पर चार बाइट, आउटपुट में चार बाइट, आसान और सरल।

अब आइए incr (एक गैर-तुच्छ विध्वंसक के साथ मामला) को देखें।

 movl (%rsi), %eax addl $1, %eax movl %eax, (%rsi) movl %eax, (%rdi) movq %rdi, %rax retq 

यहाँ, रजिस्टर में obj पास नहीं किया गया है, इस तथ्य के बावजूद कि यहाँ एक ही शब्दार्थ के साथ 4 बाइट्स हैं। यहाँ obj पास किया गया है और पते पर वापस आ गया है। यहां कॉलर वापसी मूल्य के लिए कुछ स्थान रखता है और हमें इस जगह को आरडी में एक पॉइंटर देता है, और कॉल करने वाला हमें तर्क% rsi के अगले रजिस्टर में रिटर्न वैल्यू obj के लिए एक पॉइंटर देता है। हम मान (% rsi) से निकालते हैं, 1 जोड़ते हैं, इसे वापस (% rsi) में सहेजते हैं ताकि ओब्ज के मान को अपडेट किया जा सके और फिर (trivially) 4% बाइट्स obj को स्लॉट में वापस करने के लिए% rdi के लिए इंगित किया गया। अंत में, हम कॉलर को% rdi से% rax तक पारित मूल सूचक को कॉपी करते हैं, क्योंकि x86-64 ABI दस्तावेज़ (पृष्ठ 22) हमें ऐसा करने के लिए कहता है।

कारण बार फू से इतना अलग है क्योंकि बार में एक nontrivial विध्वंसक है, और x86-64I (पृष्ठ 19) विशेष रूप से बताता है:

यदि C ++ ऑब्जेक्ट में एक nontrivial कॉपी कंस्ट्रक्टर या एक nontrivial डिस्ट्रक्टर है, तो इसे एक अदृश्य लिंक के माध्यम से पारित किया जाता है (पैरामीटर सूची में ऑब्जेक्ट को पॉइंटर [...] से बदल दिया जाता है)

बाद में Itanium C ++ ABI दस्तावेज़ निम्नलिखित को परिभाषित करता है:

यदि कॉल के उद्देश्य के लिए पैरामीटर प्रकार nontrivial है, तो कॉल करने वाले को एक अस्थायी स्थान आवंटित करना होगा और इस अस्थायी स्थान के लिए एक लिंक पास करना होगा:
[...]
एक प्रकार को कॉल के उद्देश्य के लिए nontrivial माना जाता है:

इसमें एक nontrivial कॉपी कंस्ट्रक्टर, एक मूविंग कंस्ट्रक्टर, एक डिस्ट्रक्टर, या इसके सभी मूविंग और कॉपी कंस्ट्रक्टर्स को हटा दिया गया है।

तो यह सब कुछ समझाता है: बार की गरीब कोड पीढ़ी है क्योंकि यह एक अदृश्य लिंक के माध्यम से पारित किया जाता है। यह एक अदृश्य लिंक के माध्यम से प्रेषित होता है क्योंकि दो स्वतंत्र परिस्थितियों का एक अशुभ संयोजन होता है:

• ABI दस्तावेज़ का कहना है कि गैर-तुच्छ विध्वंसक वस्तुओं को अदृश्य लिंक के माध्यम से पारित किया जाता है
• बार में एक गैर-तुच्छ विध्वंसक है।

यह एक क्लासिक सिल्लोगिज्म है : पहला बिंदु मुख्य आधार है, दूसरा निजी है। नतीजतन, बार एक अदृश्य लिंक के माध्यम से प्रेषित होता है।

कोई हमें एक नपुंसकता दे:

• सभी लोग नश्वर हैं
• सुकरात एक आदमी है।
• नतीजतन, सुकरात नश्वर है।

यदि हम निष्कर्ष का खंडन करना चाहते हैं "सुकरात नश्वर है," हमें परिसर में से एक का खंडन करना चाहिए: या तो मुख्य बात (शायद कुछ लोग नश्वर नहीं हैं) का खंडन करने के लिए, या निजी का खंडन करने के लिए (शायद सुकरात एक व्यक्ति नहीं है)।

बार के लिए एक रजिस्टर (फू की तरह) में पारित होने के लिए, हमें दो परिसरों में से एक का खंडन करना चाहिए। मानक C ++ पथ निजी आधार को नष्ट करने के लिए बार को एक तुच्छ विध्वंसक बनाने के लिए है। लेकिन एक और तरीका है!

कैसे [[trivial_abi]] समस्या हल करता है

नई क्लैंग विशेषता मुख्य आधार को नष्ट कर देती है। क्लैग इस प्रकार है ABI दस्तावेज़ का विस्तार:

यदि कॉल के उद्देश्य के लिए पैरामीटर प्रकार nontrivial है, तो कॉल करने वाले को एक अस्थायी स्थान आवंटित करना होगा और इस अस्थायी स्थान के लिए एक लिंक पास करना होगा:
[...]
एक प्रकार को कॉल के उद्देश्य से nontrivial माना जाता है यदि इसे [[trivial_abi]] और के रूप में चिह्नित किया जाता है:
इसमें एक nontrivial कॉपी कंस्ट्रक्टर, एक मूविंग कंस्ट्रक्टर, एक डिस्ट्रक्टर, या इसके सभी मूविंग और कॉपी कंस्ट्रक्टर्स को हटा दिया गया है।

यहां तक ​​कि अगर एक nontrivial मूविंग कंस्ट्रक्टर या डिस्ट्रक्टर के साथ एक वर्ग को कॉल के उद्देश्य के लिए तुच्छ माना जा सकता है, अगर इसे [[trivial_abi] के रूप में चिह्नित किया गया है।

तो अब, Clang का उपयोग करते हुए, हम इस तरह लिख सकते हैं:

 #define TRIVIAL_ABI __attribute__((trivial_abi)) struct TRIVIAL_ABI Baz { int value; ~Baz() {} // deliberately non-trivial }; 

संकलन <br>, और incr <Foo> के समान कोड प्राप्त करें!

चेतावनी # 1: [[trivial_abi]] कभी-कभी कुछ नहीं करता है

मुझे उम्मीद है कि हम मानक पुस्तकालय प्रकारों पर "कॉलिंग उद्देश्यों के लिए तुच्छ" बना सकते हैं, जैसे:

 template<class T, class D> struct TRIVIAL_ABI trivial_unique_ptr : std::unique_ptr<T, D> { using std::unique_ptr<T, D>::unique_ptr; }; 

काश, यह काम नहीं करता। यदि आपकी कक्षा में कोई आधार वर्ग या गैर-स्थिर फ़ील्ड हैं, जो "कॉल के उद्देश्य के लिए nontrivial" हैं, तो क्लैंग का विस्तार उस रूप में होता है, जिसमें यह लिखा जाता है कि अब आपकी कक्षा "अपरिवर्तनीय रूप से", और विशेषता का कोई प्रभाव नहीं पड़ेगा। (कोई नैदानिक ​​संदेश जारी नहीं किया गया है। इसका मतलब है कि आप वैकल्पिक विशेषता के रूप में क्लास टेम्पलेट में [[trivial_abi]] का उपयोग कर सकते हैं, और कक्षा "सशर्त रूप से तुच्छ" होगी, जो कभी-कभी उपयोगी होती है। नुकसान, ज़ाहिर है, यह है कि आप कर सकते हैं। वर्ग को तुच्छ के रूप में चिह्नित करें, और फिर पाएं कि संकलक ने चुपचाप इसे ठीक कर दिया है।)

यदि आपकी कक्षा में वर्चुअल बेस क्लास, या वर्चुअल फ़ंक्शंस हैं, तो संदेशों के बिना विशेषता को अनदेखा किया जाता है। इन मामलों में, यह रजिस्टरों में फिट नहीं हो सकता है, और मुझे नहीं पता कि आप इसे मूल्य द्वारा पास करना चाहते हैं, लेकिन आप शायद जानते हैं।

इसलिए, जहां तक ​​मुझे पता है, "मानक उपयोगितावादी प्रकार" के लिए TRIVIAL_ABI का उपयोग करने का एकमात्र तरीका है, जैसे कि वैकल्पिक <T>, unique_ptr <T> और साझा_ptr <T> है।

• उन्हें खरोंच से खुद को लागू करें और विशेषता को लागू करें, या
• libc ++ की अपनी स्थानीय प्रतिलिपि में विराम करें और वहां विशेषता अपने हाथों से डालें

(खुले स्रोत की दुनिया में, दोनों विधियां अनिवार्य रूप से समान हैं)

चेतावनी # 2: विध्वंसक जिम्मेदारी

फू / बार के साथ उदाहरण में, कक्षा में एक खाली विध्वंसक है। हमारी कक्षा को वास्तव में एक निरर्थक विनाशकारी होने दो।

 struct Up1 { int value; Up1(Up1&& u) : value(u.value) { u.value = 0; } ~Up1() { puts("destroyed"); } }; 

यह आपके लिए परिचित होना चाहिए, यह विशिष्ट_प्रति <int> है, सीमा तक सरलीकृत, हटाए जाने पर संदेश के साथ।

TRIVIAL_ABI के बिना, incr <Up1> बस incr <Bar> की तरह दिखता है:

 movl (%rsi), %eax addl $1, %eax movl %eax, (%rdi) movl $0, (%rsi) movq %rdi, %rax retq 

TRIVIAL_ABI के साथ, incr बड़ा और डरावना लगता है !

 pushq %rbx leal 1(%rdi), %ebx movl $.L.str, %edi callq puts movl %ebx, %eax popq %rbx retq 

पारंपरिक कॉलिंग कन्वेंशन में, एक गैर-तुच्छ विध्वंसक प्रकार के साथ हमेशा एक अदृश्य लिंक द्वारा पारित किया जाता है, जिसका अर्थ है कि प्राप्त पक्ष (इस मामले में incr) हमेशा इस ऑब्जेक्ट के मालिक के बिना एक पैरामीटर ऑब्जेक्ट के लिए एक पॉइंटर को स्वीकार करता है। कॉल करने वाले के पास ऑब्जेक्ट का स्वामित्व होता है।

जब रजिस्टरों में [[trivial_abi]] के साथ एक प्रकार पारित किया जाता है, तो हम अनिवार्य रूप से पैरामीटर ऑब्जेक्ट की एक प्रति बनाते हैं।

चूँकि x86-64 के पास लौटने के लिए केवल एक ही रजिस्टर है (तालियाँ), कहा जाता है कि फ़ंक्शन के पास अंत में ऑब्जेक्ट को वापस करने का कोई तरीका नहीं है। तथाकथित फ़ंक्शन को उस वस्तु का स्वामित्व लेना चाहिए जिसे हमने इसे पारित किया था! इसका मतलब यह है कि जब कहा जाता है, तो फ़ंक्शन को पैरामीटर ऑब्जेक्ट के विनाशकर्ता को कॉल करना होगा।

हमारे पिछले उदाहरण में, फू / बार / बाज, विध्वंसक कहा जाता है, लेकिन यह खाली था, और हमने इसे नोटिस नहीं किया। अब incr <Up2> में हमें अतिरिक्त कोड दिखाई देता है जो कि विध्वंसक द्वारा उत्पन्न होता है जिसे फंक्शन कहा जाता है।

यह माना जा सकता है कि यह अतिरिक्त कोड कुछ उपयोगकर्ता मामलों में उत्पन्न हो सकता है। लेकिन, इसके विपरीत, विध्वंसक की कॉल कहीं भी प्रकट नहीं होती है! इसे incr में कहा जाता है क्योंकि इसे कॉलिंग फ़ंक्शन में नहीं कहा जाता है। और सामान्य तौर पर, मूल्य और लाभ संतुलित होंगे।

चेतावनी # 3: विनाशकारी आदेश

एक तुच्छ एबीआई के साथ एक पैरामीटर के लिए विध्वंसक को बुलाया फ़ंक्शन द्वारा बुलाया जाएगा, और कॉलिंग एक (चेतावनी नंबर 2) नहीं। रिचर्ड स्मिथ बताते हैं कि इसका मतलब है कि इसका मतलब है कि उसे उस क्रम में नहीं बुलाया जाएगा जिसमें अन्य मापदंडों के विध्वंसक स्थित हैं।

 struct TRIVIAL_ABI alpha { alpha() { puts("alpha constructed"); } ~alpha() { puts("alpha destroyed"); } }; struct beta { beta() { puts("beta constructed"); } ~beta() { puts("beta destroyed"); } }; void foo(alpha, beta) {} int main() { foo(alpha{}, beta{}); } 

यह कोड प्रिंट करता है:

 alpha constructed beta constructed alpha destroyed beta destroyed 

जब TRIVIAL_ABI को [[clang :: trivial_abi]] के रूप में परिभाषित किया गया है, तो यह प्रिंट करता है:

 alpha constructed beta constructed beta destroyed alpha destroyed 

"तुच्छ रूप से स्थानांतरित करने योग्य" / "स्थानांतरित-स्थानांतरित" वस्तु के साथ संबंध

कोई रिश्ता नहीं ..., हुह?

जैसा कि आप देख सकते हैं, चलती कंस्ट्रक्टर, डिस्ट्रक्टर, या डिफॉल्ट कंस्ट्रक्टर के लिए किसी भी विशिष्ट शब्दार्थ के लिए [[trivial_abi]] वर्ग की कोई आवश्यकता नहीं है। कोई भी विशेष वर्ग संभवतः तुच्छ रूप से स्थानापन्न होगा, केवल इसलिए कि अधिकांश वर्ग तुच्छ रूप से स्थानापन्न हैं।

हम केवल ऑफसेट_प्ट्र वर्ग बना सकते हैं ताकि यह तुच्छ रूप से स्थानांतरित न हो:

 template<class T> class TRIVIAL_ABI offset_ptr { intptr_t value_; public: offset_ptr(T *p) : value_((const char*)p - (const char*)this) {} offset_ptr(const offset_ptr& rhs) : value_((const char*)rhs.get() - (const char*)this) {} T *get() const { return (T *)((const char *)this + value_); } offset_ptr& operator=(const offset_ptr& rhs) { value_ = ((const char*)rhs.get() - (const char*)this); return *this; } offset_ptr& operator+=(int diff) { value_ += (diff * sizeof (T)); return *this; } }; int main() { offset_ptr<int> top = &a[4]; top = incr(top); assert(top.get() == &a[5]); } 

यहाँ पूरा कोड है।
जब TRIVIAL_ABI को परिभाषित किया जाता है, तो क्लैंग ट्रंक इस परीक्षण को -O0 और -O1 में पास करता है, लेकिन -O2 (यानी जैसे ही यह इनलाइन कॉल को trivial_offset_ptr - ऑपरेटर + = और कॉपी कंस्ट्रक्टर को कॉल करने की कोशिश करता है), यह मुखर पर क्रैश हो जाता है।

तो एक और चेतावनी। यदि आपका प्रकार इस सूचक के साथ कुछ पागल करता है, तो आप संभवतः इसे रजिस्टरों में पारित नहीं करना चाहेंगे।

बग 37319 , वास्तव में, प्रलेखन के लिए एक अनुरोध। इस मामले में, यह पता चला है कि प्रोग्रामर को जिस तरह से कोड काम करने का कोई तरीका नहीं है। हम कहते हैं कि value_ का मान इस पॉइंटर के मान पर निर्भर होना चाहिए, लेकिन कॉलिंग और तथाकथित फ़ंक्शन के बीच की सीमा पर, ऑब्जेक्ट रजिस्टरों में है और इसके लिए पॉइंटर मौजूद नहीं है! इसलिए, कॉलिंग फ़ंक्शन इसे मेमोरी में लिखता है, और इस पॉइंटर को फिर से पास करता है, और कैसे कहा जाता है कि वैल्यू_ को लिखने के लिए सही फ़ंक्शन को सही मान की गणना करनी चाहिए? शायद यह पूछना बेहतर है कि यह कैसे काम करता है -O0? यह कोड बिल्कुल भी काम नहीं करना चाहिए।

इसलिए, यदि आप [[trivial_abi]] का उपयोग करना चाहते हैं, तो आपको सदस्य कार्यों (न केवल विशेष, बल्कि सामान्य रूप से) से बचना चाहिए जो ऑब्जेक्ट के स्वयं के पते ("आवश्यक" शब्द के कुछ अपरिभाषित अर्थ पर) पर बहुत अधिक निर्भर करते हैं।

सहज रूप से, जब एक वर्ग को [[trivial_abi]] के रूप में चिह्नित किया जाता है, जब भी आप कॉपी करने की उम्मीद करते हैं, तो आप कॉपी प्लस मेमसीपी प्राप्त कर सकते हैं। और इसी तरह, जब आप एक चाल की उम्मीद करते हैं, तो आप वास्तव में चाल प्लस मेम्ची प्राप्त कर सकते हैं।

जब एक प्रकार "तुच्छ रूप से स्थानांतरित करने योग्य" होता है (जैसा कि मेरे द्वारा C ++ Now में परिभाषित किया गया है ), तो कभी भी आप नकल और विनाश की उम्मीद करते हैं, तो आप वास्तव में यादगार हो सकते हैं। और इसी तरह, जब आप विस्थापन और विनाश की उम्मीद करते हैं, तो आप वास्तव में यादगार हो सकते हैं। वास्तव में, यदि हम "तुच्छ स्थानांतरण" के बारे में बात करते हैं, तो विशेष कार्यों के लिए कॉल खो जाते हैं, लेकिन जब कक्षा में [[trivial_abi]] क्लैंग की विशेषता होती है, तो कॉल गुम नहीं होती हैं। आपको केवल उन कॉल के अलावा (जैसा कि यह था) यादगार थी। यह (सॉर्ट) मेमसीपी वह मूल्य है जो आप तेजी से, कॉल रजिस्टर सम्मेलन के लिए भुगतान करते हैं।

आगे पढ़ने के लिए लिंक:

नवंबर 2017 से अकीरा हतननाका का सीफ़-देव धागा
आधिकारिक क्लैंग प्रलेखन
इकाई trivial_abi के लिए परीक्षण करती है
बग 37319: trivial_offset_ptr संभवतः काम नहीं कर सकता