rust 🚀 - एलएलवीएम लूप ऑप्टिमाइज़ेशन सुरक्षित कार्यक्रमों को क्रैश बना सकता है

अनुकूलित कोड का LLVM IR है

; Function Attrs: noreturn nounwind readnone uwtable
define internal void @_ZN4main20h5ec738167109b800UaaE() unnamed_addr #0 {
entry-block:
  unreachable
}

इस तरह का अनुकूलन मुख्य धारणा को तोड़ता है जिसे आम तौर पर निर्जन प्रकारों पर पकड़ होना चाहिए: उस प्रकार का मान होना असंभव होना चाहिए।
जंग- lang / rfcs # 1216 इस प्रकार के जंग को स्पष्ट रूप से संभालने का प्रस्ताव करता है। यह सुनिश्चित करने में प्रभावी हो सकता है कि LLVM को कभी भी उन्हें संभालना नहीं पड़ता है और जरूरत पड़ने पर विचलन सुनिश्चित करने के लिए उपयुक्त कोड को इंजेक्ट किया जाता है (IIUIC इसे उपयुक्त विशेषताओं या आंतरिक कॉल के साथ प्राप्त किया जा सकता है)।
इस विषय पर हाल ही में LLVM मेलिंग सूची में भी चर्चा की गई है: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088095.html

ranma42 29 सित॰ 2015

triage: I- नामांकित

बुरा लगता है! यदि LLVM के पास "हां, यह लूप वास्तव में अनंत है" कहने का कोई तरीका नहीं है, हालांकि तब हमें बस चर्चा के लिए अपस्ट्रीम चर्चा के लिए बैठना पड़ सकता है।

alexcrichton 29 सित॰ 2015

अनंत छोरों को दूर अनुकूलित होने से रोकने का एक तरीका उनके अंदर unsafe {asm!("" :::: "volatile")} जोड़ना है। यह llvm.noop.sideeffect आंतरिक के समान है जिसे LLVM मेलिंग सूची में प्रस्तावित किया गया है, लेकिन यह कुछ अनुकूलन को रोक सकता है।
प्रदर्शन के नुकसान से बचने के लिए और अभी भी गारंटी देने के लिए कि डायवर्जिंग फ़ंक्शन / लूप्स को अनुकूलित नहीं किया जाता है, मेरा मानना है कि यदि खाली निर्जन मान हैं तो खाली गैर-आशावादी लूप (यानी loop { unsafe { asm!("" :::: "volatile") } } ) सम्मिलित करने के लिए पर्याप्त होना चाहिए। गुंजाइश।
यदि LLVM उस कोड का अनुकूलन करता है जिसे इस बिंदु पर विचलन करना चाहिए कि यह अब और विचलन नहीं करता है, तो ऐसे लूप सुनिश्चित करेंगे कि नियंत्रण प्रवाह अभी भी आगे बढ़ने में असमर्थ है।
"भाग्यशाली" मामले में जिसमें एलएलवीएम डाइवर्जिंग कोड को अनुकूलित करने में असमर्थ है, ऐसे लूप को डीसीई द्वारा हटा दिया जाएगा।

ranma42 29 सित॰ 2015

क्या यह # 18785 से संबंधित है? यूबी होने के लिए अनंत पुनरावृत्ति के बारे में यह एक है, लेकिन ऐसा लगता है कि मौलिक कारण समान हो सकता है: एलएलवीएम को रोकने के लिए साइड इफेक्ट नहीं माना जाता है, इसलिए यदि किसी फ़ंक्शन के रुकने के अलावा कोई साइड इफेक्ट नहीं है, तो यह ऑप्टिमाइज़ करने के लिए खुश है इसे दूर।

geofft 29 सित॰ 2015

👍1

@geofft

यह एक ही मुद्दा है।

arielb1 29 सित॰ 2015

हां, ऐसा ही लग रहा है। उस मुद्दे को और नीचे रखते हुए, वे दिखाते हैं कि undef कैसे प्राप्त किया जाए, जिससे मुझे लगता है कि एक (प्रतीत होता है कि सुरक्षित) प्रोग्राम क्रैश करना मुश्किल नहीं है।

RalfJung 29 सित॰ 2015

: +1:

simnalamburt 29 सित॰ 2015

क्रैश, या, संभवतः इससे भी बदतर हार्दिक https://play.rust-lang.org/?gist=15a325a795244192bdce&version=stable

ranma42 29 सित॰ 2015

इसलिए मैं सोच रहा था कि जब तक कोई यह रिपोर्ट नहीं करेगा। :) मेरी राय में, सबसे अच्छा समाधान निश्चित रूप से होगा यदि हम एलएलवीएम को बता सकते हैं कि संभावित अनंत छोरों के बारे में इतना आक्रामक न हो। अन्यथा, केवल एक चीज जो मुझे लगता है कि हम कर सकते हैं रूस्त में एक रूढ़िवादी विश्लेषण करना है जो यह निर्धारित करता है:

पाश या समाप्त हो जाएगा
लूप के साइड-इफेक्ट्स होंगे (I / O ऑपरेशन आदि, मैं ठीक से भूल जाता हूं कि इसे C में कैसे परिभाषित किया गया है)

या तो यह अपरिभाषित व्यवहार से बचने के लिए पर्याप्त होना चाहिए।

nikomatsakis 1 अक्तू॰ 2015

triage: पी-मीडियम

हम यह देखना चाहेंगे कि एलएलवीएम हमारे पक्ष में बहुत प्रयास करने से पहले क्या करेगा, और यह अभ्यास में समस्याओं का कारण बनने की अपेक्षाकृत कम संभावना है (हालांकि मैंने कंपाइलर विकसित करने के दौरान व्यक्तिगत रूप से इसे हिट किया है)। इस बारे में चिंतित होने के लिए कोई पिछड़ेपन की अक्षमता के मुद्दे नहीं हैं।

nikomatsakis 1 अक्तू॰ 2015

एलएलवीएम मेलिंग सूची चर्चा से उद्धरण:

 The implementation may assume that any thread will eventually do one of the following:
   - terminate
   - make a call to a library I/O function
   - access or modify a volatile object, or
   - perform a synchronization operation or an atomic operation

 [Note: This is intended to allow compiler transformations such as removal of empty loops, even
  when termination cannot be proven. — end note ]

dotdash 1 अक्तू॰ 2015

@dotdash आपके द्वारा उद्धृत अंश C ++ विनिर्देशन से आता है; यह मूल रूप से "यह कैसे होता है इसका दुष्प्रभाव सी में परिभाषित किया गया है" का उत्तर है (मानक समिति द्वारा भी पुष्टि की गई है: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528 .htm)।

एलएलवीएम आईआर के अपेक्षित व्यवहार के बारे में कुछ भ्रम है। https://llvm.org/bugs/show_bug.cgi?id=24078 से पता चलता है कि LLVM IR में अनंत लूप के शब्दार्थों का कोई सटीक और स्पष्ट विनिर्देश नहीं है। यह C ++ के शब्दार्थों के साथ संरेखित करता है, जो ऐतिहासिक कारणों से और सुविधा के लिए सबसे अधिक संभावना है (मैं केवल https://groups.google.com/forum/# .topic/llvm-dev/j2vlIECKkdE को ट्रैक करने में कामयाब रहा हूं) यह स्पष्ट रूप से एक समय को संदर्भित करता है जब अनंत छोरों को अनुकूलित नहीं किया गया था, तो कुछ समय पहले C / C ++ स्पेक्स को इसे अनुमति देने के लिए अद्यतन किया गया था)।

धागे से यह स्पष्ट है कि सी ++ कोड को यथासंभव प्रभावी रूप से अनुकूलित करने की इच्छा है (यानी अनंत छोरों को हटाने के अवसर को ध्यान में रखते हुए), लेकिन एक ही धागे में कई डेवलपर्स (कुछ जिनमें सक्रिय रूप से एलएलवीएम में योगदान है) अनंत छोरों को संरक्षित करने की क्षमता में रुचि दिखाई, क्योंकि वे अन्य भाषाओं के लिए आवश्यक हैं।

ranma42 2 अक्तू॰ 2015

👍1

@ ranma42 मैं इसके बारे में जानता हूं, मैंने इसे केवल संदर्भ के लिए उद्धृत किया है, क्योंकि इसके आसपास काम करने की एक संभावना जंग में इस तरह के छोरों का पता लगाने और एलएलवीएम को इस अनुकूलन को करने से रोकने के लिए उपरोक्त में से एक को जोड़ना होगा।

dotdash 2 अक्तू॰ 2015

क्या यह एक ध्वनि मुद्दा है? यदि हां, तो हमें इसे इस तरह टैग करना चाहिए।

bstrie 30 नव॰ 2015

हां, @ ranma42 के उदाहरण के बाद, इस तरह से पता चलता है कि यह कैसे सरणी सीमाओं की जांच को आसानी से हरा देता है। खेल का मैदान लिंक

bluss 30 नव॰ 2015

👍4

@bluss

नीति यह है कि गलत-कोड के मुद्दे जो कि ध्वनि के मुद्दे हैं (अर्थात उनमें से अधिकांश) I-wrong टैग किए जाने चाहिए।

arielb1 2 दिस॰ 2015

तो बस पूर्व चर्चा को फिर से शुरू करने के लिए, यहां वास्तव में दो विकल्प हैं जिन्हें मैं देख सकता हूं:

समाधान प्रदान करने के लिए LLVM की प्रतीक्षा करें।
जहां भी अनंत लूप या अनंत पुनरावृत्ति (# 18785) हो सकती है, वहां नो-ऑप एसएसएम स्टेटमेंट पेश करें।

उत्तरार्द्ध खराब है, क्योंकि यह अनुकूलन को बाधित कर सकता है, इसलिए हम इसे कुछ हद तक करना चाहते हैं - मूल रूप से जहां भी हम खुद को साबित नहीं कर सकते हैं। आप यह भी बता सकते हैं कि यह कैसे LLVM का अनुकूलन करने के लिए थोड़ा अधिक बांधता है - यानी, केवल परिचय अगर हम एक परिदृश्य का पता लगा सकते हैं कि LLVM एक अनंत लूप / पुनरावृत्ति पर विचार कर सकता है - लेकिन (क) ट्रैकिंग LLVM (b) की आवश्यकता होगी ) की आवश्यकता है, कम से कम, मेरे पास से गहरा ज्ञान है।

nikomatsakis 4 अग॰ 2016

समाधान प्रदान करने के लिए LLVM की प्रतीक्षा करें।

इस मुद्दे पर एलएलवीएम बग क्या है?

gnzlbg 1 सित॰ 2016

साइड-नोट: while true {} इस व्यवहार को प्रदर्शित करता है । हो सकता है कि लिंट को त्रुटि के आधार पर अपग्रेड कर दिया जाए और यह नोट कर लिया जाए कि यह वर्तमान में अपरिभाषित व्यवहार प्रदर्शित कर सकता है?

oli-obk 11 अक्तू॰ 2016

👍1

इसके अलावा, ध्यान दें कि यह सी। एलएलवीएम के लिए यह तर्क अमान्य है कि इस तर्क का अर्थ है कि क्लैंग में एक बग है।

void foo() { while (1) { } }

void create_null() {
        foo();

        int i = 0;
        while (i < 100) { i += 1; }
}

__attribute__((noreturn))
void use_null() {
        __builtin_unreachable();
}


int main() {
        create_null();
        use_null();
}

यह अनुकूलन के साथ दुर्घटनाग्रस्त हो जाता है; यह C11 मानक के तहत अमान्य व्यवहार है :

An iteration statement whose controlling expression is not a constant
expression, [note 156] that performs no  input/output  operations,
does  not  access  volatile  objects,  and  performs  no synchronization or
atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be   assumed   by   the
implementation to terminate. [note 157]

156: An omitted controlling expression is replaced by a nonzero constant,
     which is a constant expression.
157: This  is  intended  to  allow  compiler  transformations  such  as
     removal  of  empty  loops  even  when termination cannot be proven.

"जिनकी नियंत्रण अभिव्यक्ति एक स्थिर अभिव्यक्ति नहीं है" पर ध्यान दें - while (1) { } , 1 एक निरंतर अभिव्यक्ति है, और इस प्रकार हटाया नहीं जा सकता है ।

strega-nil 30 नव॰ 2016

👍10

क्या लूप हटाने से कोई ऑप्टिमाइज़ेशन पास होता है जिसे हम बस निकाल सकते हैं?

oli-obk 30 नव॰ 2016

@ubsan

क्या आपने एलएलवीएम के बगज़िला या उस भरे हुए के लिए एक बग रिपोर्ट ढूंढी? ऐसा लगता है कि C ++ में अनंत छोरों कि _can_ कभी भी अपरिभाषित व्यवहार नहीं हैं, लेकिन C में वे परिभाषित व्यवहार हैं (या तो उन्हें कुछ मामलों में सुरक्षित रूप से हटाया जा सकता है, या वे दूसरों में नहीं कर सकते हैं)।

gnzlbg 30 नव॰ 2016

@gnzlbg मैं अब बग दर्ज कर रहा हूं।

https://llvm.org/bugs/show_bug.cgi?id=31217

strega-nil 30 नव॰ 2016

# 42009 से खुद को दोहराते हुए: यह बग, कुछ परिस्थितियों में, बाहरी रूप से कॉल करने योग्य फ़ंक्शन के उत्सर्जन का कारण बन सकता है, जिसमें कोई मशीन निर्देश नहीं है। ऐसा कभी नहीं होना चाहिए। यदि एलएलवीएम यह घटाता है कि pub fn को सही कोड द्वारा कभी नहीं बुलाया जा सकता है, तो उसे उस फ़ंक्शन के शरीर के रूप में कम से कम एक जाल निर्देश का उत्सर्जन करना चाहिए।

zackw 15 मई 2017

👍1

इसे आज इस ब्लॉग पोस्ट में लाया गया: https://blog.rom1v.com/2017/09/gnirehtet-rewritten-rust/rust/

एक सरल प्रजनन के साथ: https://play.rust-lang.org/?gist=e622f8a672fbc57ecc63eb4450d2fc0a&version=stable

steveklabnik 21 सित॰ 2017

इसके लिए LLVM बग https://bugs.llvm.org/show_bug.cgi?id=965 (2006 में खोला गया) है।

sunfishcode 22 सित॰ 2017

😕9

@ ज़ैकव एलएलवीएम के लिए एक झंडा है: TrapUnreachable । मैंने इसका परीक्षण नहीं किया है, लेकिन यह आपकी चिंता को दूर करने के लिए Options.TrapUnreachable = true; से LLVMRustCreateTargetMachine जोड़ना चाहता है। यह संभावना है कि इसकी कम लागत है जो इसे डिफ़ॉल्ट रूप से किया जा सकता है, हालांकि मैंने कोई माप नहीं किया है।

@ oli-obk यह दुर्भाग्य से सिर्फ लूप-डिलीशन पास नहीं है। समस्या व्यापक धारणाओं से उत्पन्न होती है, उदाहरण के लिए: (ए) शाखाओं का कोई साइड इफेक्ट नहीं है, (बी) फ़ंक्शन जिसमें साइड इफेक्ट्स के साथ कोई निर्देश नहीं है, कोई साइड इफेक्ट नहीं है, और (सी) बिना किसी साइड इफेक्ट वाले कार्यों को स्थानांतरित नहीं किया जा सकता है या नहीं। नष्ट कर दिया।

sunfishcode 27 सित॰ 2017

👍2

ऐसा लगता है कि एक पैच है: https://reviews.llvm.org/D38336

steveklabnik 28 सित॰ 2017

@sunfishcode , https://reviews.llvm.org/D38336 पर आपके LLVM पैच की तरह दिखता है, जिसे 3 अक्टूबर को "स्वीकार" किया गया था, क्या आप LLVM की रिलीज़ प्रक्रिया के बारे में इसका क्या मतलब है, इस पर अपडेट दे सकते हैं? स्वीकृति से परे अगला कदम क्या है, और क्या आपको इस बात का अंदाजा है कि भविष्य के एलएलवीएम में यह पैच क्या होगा?

bstrie 2 नव॰ 2017

मैंने ऑफ़लाइन कुछ लोगों के साथ बात की जिन्होंने सुझाव दिया कि हमारे पास एक llvmdev धागा होगा। धागा यहाँ है:

http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html

अब यह निष्कर्ष निकाला गया है, जिसके परिणामस्वरूप मुझे अतिरिक्त बदलाव करने की आवश्यकता है। मुझे लगता है कि बदलाव अच्छे होंगे, हालांकि वे मुझे करने के लिए थोड़ा और समय लेंगे।

sunfishcode 2 नव॰ 2017

👍1

अपडेट के लिए धन्यवाद, और आपके प्रयासों के लिए बहुत बहुत धन्यवाद!

bstrie 2 नव॰ 2017

ध्यान दें कि https://reviews.llvm.org/rL317729 LLVM में उतरा है। इस पैच में एक अनुवर्ती पैच लगाने की योजना है, जो डिफ़ॉल्ट रूप से परिभाषित लूप को परिभाषित व्यवहार करता है, इसलिए AFAICT हम सभी को इंतजार करने की आवश्यकता है और अंततः यह हमारे लिए अपस्ट्रीम को हल किया जाएगा।

bstrie 9 नव॰ 2017

🎉2

@zackw मैं अब कोई कोड युक्त कार्यों की समस्या को ठीक करने # 45,920 बना लिया है।

@bstrie हां, पहला कदम उतरा हुआ है, और मैं

sunfishcode 10 नव॰ 2017

🎉6

मैं इसे अभी रद्द नहीं कर सकता: https://play.rust-lang.org/?gist=529bd5ab326f7b627e559f64d514312f&version=stable

jsgf 8 फ़र॰ 2018

@jsgf स्टिल

kennytm 8 फ़र॰ 2018

👍2

@kennytm Woops, कोई बात नहीं।

jsgf 15 फ़र॰ 2018

ध्यान दें कि https://reviews.llvm.org/rL317729 LLVM में उतरा है। इस पैच में एक अनुवर्ती पैच लगाने की योजना है, जो डिफ़ॉल्ट रूप से परिभाषित लूप को परिभाषित व्यवहार करता है, इसलिए AFAICT हम सभी को इंतजार करने की आवश्यकता है और अंततः यह हमारे लिए अपस्ट्रीम को हल किया जाएगा।

इस टिप्पणी के कई महीने हो चुके हैं। किसी को पता है कि अनुवर्ती पैच हुआ या अभी भी होगा?

वैकल्पिक रूप से, ऐसा लगता है कि हम जिस एलएलवीएम संस्करण का उपयोग कर रहे हैं, उसमें llvm.sideeffect आंतरिक मौजूद हैं: क्या हम इसे एलएलवीएम छोरों में रस्ट अनन्त लूप्स का अनुवाद करके स्वयं को ठीक कर सकते हैं जिसमें साइडइफेक्ट विक्षिप्त हैं?

japaric 7 अग॰ 2018

जैसा कि देखा गया है कि https://github.com/rust-lang/rust/issues/38136 और https://github.com/rust-lang/rust/issues/54214 , यह आने वाले panic_implementation साथ विशेष रूप से बुरा है loop {} , और इससे panic! UB की सभी घटनाएं बिना किसी unsafe कोड के साथ हो जाएंगी। कौन सा ... शायद इससे भी बदतर हो सकता है।

Ekleog 14 सित॰ 2018

बस इस मुद्दे पर एक और प्रकाश में आया। यहाँ एक उदाहरण है:

pub struct Container<'f> {
    string: &'f str,
    num: usize,
}

impl<'f> From<&'f str> for Container<'f> {
    #[inline(always)]
    fn from(string: &'f str) -> Container<'f> {
        Container::from(string)
    }
}

fn main() {
    let x = Container::from("hello");
    println!("{} {}", x.string, x.num);

    let y = Container::from("hi");
    println!("{} {}", y.string, y.num);

    let z = Container::from("hello");
    println!("{} {}", z.string, z.num);
}

यह उदाहरण स्थिर, बीटा और रात को विश्वसनीय रूप से अलग-थलग है, और दिखाता है कि किसी भी प्रकार के निर्विवाद मूल्यों का निर्माण करना कितना आसान है। यहां यह खेल के मैदान पर है ।

SergioBenitez 27 सित॰ 2018

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

रिलीज़ बिल्ड में, LLVM यह मान सकता है कि आपके पास अनंत पुनरावर्तन नहीं है, और वह दूर को अनुकूलित करता है ( mwe )। इसका AFAICT के साथ कोई लेना-देना नहीं है, बल्कि https://stackoverflow.com/a/5905171/1422197 के साथ

gnzlbg 27 सित॰ 2018

@gnzlbg क्षमा करें, लेकिन आप सही नहीं हैं।

कार्यक्रम रिलीज मोड में segfaults है। वह संपूर्ण बिंदु है; यह अनुपयोगी व्यवहार का परिणाम है - कि एलएलवीएम और रस्ट के शब्दार्थ यहां सहमति में नहीं हैं - कि मैं जंग के साथ एक सुरक्षित जंग कार्यक्रम को लिख सकता हूं और संकलित कर सकता हूं, जो मुझे एकतरफा स्मृति का उपयोग करने की अनुमति देता है, मध्यस्थता स्मृति का निरीक्षण करता है, और मनमाने ढंग से प्रकारों के बीच डाली जाती है, उल्लंघन कर रहा है भाषा का शब्दार्थ। इस सूत्र में यही बात स्पष्ट की जा रही है। ध्यान दें कि मूल कार्यक्रम डिबग मोड में सेगफॉल्ट भी नहीं होता है।

आपको यह भी प्रतीत हो रहा है कि यहाँ एक _different_, नॉन-लूप ऑप्टिमाइज़ेशन हो रहा है। हालांकि यह काफी हद तक अप्रासंगिक है, लेकिन अगर ऐसा है तो यह एक अलग मुद्दे पर वारंट हो सकता है। मेरा अनुमान है कि एलएलवीएम पूंछ पुनरावृत्ति को नोटिस कर रहा है, इसे एक अनंत लूप के रूप में मानता है, और इसे दूर करने का अनुकूलन करता है, फिर से, वास्तव में यह मुद्दा क्या है।

SergioBenitez 27 सित॰ 2018

@gnzlbg अच्छा, अनंत पुनरावृत्ति ( यहाँ ) से दूर अनुकूलन के अपने mwe को थोड़ा बदलकर, यह NonZeroUsize का एक अनैतिक मूल्य उत्पन्न करता है (जो निकला ... 0, इस प्रकार एक अमान्य मान)।

और यही @SergioBenitez ने भी अपने उदाहरण के साथ किया, सिवाय इसके कि यह पॉइंटर्स के साथ है, और इस तरह एक seffault उत्पन्न करता है।

Ekleog 27 सित॰ 2018

क्या हम इस बात से सहमत हैं कि @SergioBenitez कार्यक्रम में डिबग और रिलीज़ दोनों में एक अतिप्रवाह है?

यदि हां, तो मुझे @SergioBenitez उदाहरण में कोई loop s नहीं मिल सकता है, इसलिए मुझे नहीं पता कि यह मुद्दा इस पर कैसे लागू होगा (यह मुद्दा अनंत loop s के बाद का है)। यदि मैं गलत हूं, तो कृपया मुझे loop अपने उदाहरण में इंगित करें।

जैसा कि उल्लेख किया गया है, एलएलवीएम मानता है कि अनंत पुनरावृत्ति नहीं हो सकती है (यह मानता है कि सभी धागे अंततः समाप्त हो जाते हैं), लेकिन यह इस से एक अलग मुद्दा होगा।

gnzlbg 27 सित॰ 2018

मैंने उन कार्यक्रमों में से किसी के लिए एलएलवीएम करता है या उत्पन्न कोडों का निरीक्षण नहीं किया है, लेकिन ध्यान दें कि एक segfault निराधार नहीं है, अगर segfault यह सब होता है। विशेष रूप से, स्टैक ओवरफ्लो को पकड़ा जाता है (स्टैक के अंत के बाद स्टैक प्रोबिंग + एक अनमैप्ड गार्ड पेज) और किसी भी मेमोरी सुरक्षा समस्याओं का कारण नहीं बनता है जो सीगफॉल्ट के रूप में भी दिखाई देते हैं। बेशक, segfaults स्मृति भ्रष्टाचार या वाइल्ड राइट्स / रीड या अन्य साउंडनेस समस्याओं का संकेत भी दे

hanna-kruppe 27 सित॰ 2018

@rkruppe मेरा प्रोग्राम सेगफ़ॉल्ट है क्योंकि एक यादृच्छिक मेमोरी लोकेशन के संदर्भ को निर्माण की अनुमति दी गई थी, और संदर्भ को बाद में पढ़ा गया था। कार्यक्रम को एक यादृच्छिक मेमोरी स्थान लिखने के लिए तुच्छ रूप से संशोधित किया जा सकता है, और बहुत अधिक कठिनाई के बिना, _particular और मेमोरी लोकेशन पढ़ / लिख सकते हैं।

@gnzlbg प्रोग्राम _does not_ स्टैक ओवरफ़्लो रिलीज़ मोड में। रिलीज़ मोड में, प्रोग्राम शून्य फ़ंक्शन कॉल करता है; स्टैक को स्थानीय रूप से आवंटित करने के लिए, शुद्ध रूप से कई बार धकेल दिया जाता है।

SergioBenitez 27 सित॰ 2018

प्रोग्राम रिलीज़ मोड में अतिप्रवाह को ढेर नहीं करता है।

इसलिए? केवल एक चीज जो मायने रखती है वह यह है कि उदाहरण कार्यक्रम, जो मूल रूप से fn foo() { foo() } , में अनंत पुनरावृत्ति है, जिसे LLVM द्वारा अनुमति नहीं है।

gnzlbg 27 सित॰ 2018

केवल एक चीज जो मायने रखती है वह यह है कि उदाहरण कार्यक्रम, जो मूल रूप से fn foo () {foo ()} है, में अनंत पुनरावृत्ति होती है, जिसे LLVM द्वारा अनुमति नहीं है।

मुझे नहीं पता कि आप ऐसा क्यों कह रहे हैं जैसे यह कुछ भी हल करता है। LLVM अनंत पुनरावृत्ति पर विचार करता है और UB को लूप करता है और तदनुसार अनुकूलन करता है, फिर भी यह Rust में सुरक्षित है, इस पूरे मुद्दे का पूरा बिंदु है!

hanna-kruppe 27 सित॰ 2018

Https://reviews.llvm.org/rL317729 के लेखक यहां पुष्टि करते हैं कि मैंने अभी तक अनुवर्ती पैच लागू नहीं किया है।

आप यह सुनिश्चित करने के लिए आज @llvm.sideeffect कॉल सम्मिलित कर सकते हैं कि लूप्स को अनुकूलित नहीं किया जाता है। यह कुछ अनुकूलन को अक्षम कर सकता है, लेकिन सिद्धांत में बहुत अधिक नहीं है, क्योंकि प्रमुख अनुकूलन को सिखाया गया है कि इसे कैसे समझा जाए। यदि कोई सभी छोरों या चीजों में @llvm.sideeffect कॉल करता है, जो कि लूप्स (पुनरावृत्ति, अनइंडिंग, इनलाइन एएसएम , अन्य?) में बदल सकता है, तो यह समस्या को ठीक करने के लिए सैद्धांतिक रूप से पर्याप्त है।

जाहिर है कि इसके स्थान पर दूसरा पैच होना अच्छा होगा, ताकि ऐसा करना जरूरी न हो। मुझे नहीं पता कि मैं उस पर अमल कब करूंगा।

sunfishcode 27 सित॰ 2018

कुछ छोटे अंतर हैं, लेकिन मुझे यकीन नहीं है कि यह सामग्री है या नहीं।

प्रत्यावर्तन

#[allow(unconditional_recursion)]
#[inline(never)]
pub fn via_recursion<T>() -> T {
    via_recursion()
}

fn main() {
    let a: String = via_recursion();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* <strong i="9">@rust_eh_personality</strong> {
_ZN4core3ptr13drop_in_place17h95538e539a6968d0E.exit:
  ret void
}

लूप

#[inline(never)]
pub fn via_loop<T>() -> T {
    loop {}
}

fn main() {
    let b: String = via_loop();
}

define internal void @_ZN10playground4main17h1daf53946e45b822E() unnamed_addr #2 {
start:
  unreachable
}

मेटा

रस्ट 1.29.1, रिलीज़ मोड में संकलन, एलएलवीएम आईआर को देखना।

shepmaster 27 सित॰ 2018

मुझे नहीं लगता कि हम सामान्य रूप से, पुनरावर्तन (विशेषता वस्तुओं, सी एफएफआई, आदि) का पता लगा सकते हैं, इसलिए हमें हर कॉल साइट पर llvm.sideeffect का उपयोग करना होगा जब तक कि हम यह साबित नहीं कर सकते कि कॉल साइट की पुनरावृत्ति नहीं होगी जिन मामलों में यह साबित किया जा सकता है, उनके लिए कोई पुनरावृत्ति साबित नहीं करने के लिए fn main() { main() } जैसे अधिकांश तुच्छ कार्यक्रमों को छोड़कर इंटरप्रोडेक्टोरल विश्लेषण की आवश्यकता होती है। यह जानना अच्छा हो सकता है कि इस सुधार को लागू करने का क्या प्रभाव है, और क्या इस समस्या के वैकल्पिक समाधान हैं।

gnzlbg 27 सित॰ 2018

👍1

@gnzlbg यह सच है, हालांकि आप कॉल साइटों की बजाय कार्यों की प्रविष्टियों पर @ llvm.sideeffects डाल सकते हैं।

sunfishcode 27 सित॰ 2018

अजीब बात है, मैं स्थानीय रूप से @SergioBenitez 'परीक्षण मामले में SEGFAULT को पुन: पेश नहीं कर सकता।

भी, एक ढेर अतिप्रवाह के लिए, एक अलग त्रुटि संदेश नहीं होना चाहिए? मुझे लगा कि हमारे पास "द स्टैक ओवरफ्लो" या तो प्रिंट करने के लिए कुछ कोड है?

RalfJung 29 सित॰ 2018

@RalfJung क्या आपने डिबग मोड में कोशिश की? (मैं अपनी मशीनों और खेल के मैदान में डिबग मोड में स्टैक ओवरफ्लो को मज़बूती से पुन: उत्पन्न कर सकता हूं, इसलिए शायद आपको बग को भरने की ज़रूरत है यदि आपके लिए यह मामला नहीं है)। --release आपको स्टैक ओवरफ़्लो नहीं मिलेगा क्योंकि उस सभी कोड को गलत तरीके से हटा दिया गया है।

@sunfishcode

यह सच है, हालांकि आप कॉल साइटों की बजाय कार्यों की प्रविष्टियों पर @ llvm.sideeffects डाल सकते हैं।

यह बताना मुश्किल है कि आगे का सबसे अच्छा तरीका क्या होगा, यह जाने बिना कि कौन सा अनुकूलन llvm.sideeffects रोकता है। क्या यह संभव है कि कुछ @llvm.sideeffects संभव हो सके? यदि नहीं, तो इसे हर फंक्शन कॉल में लगाना सबसे सीधी बात हो सकती है। अन्यथा, IIUC, क्या @llvm.sideeffect की जरूरत है, कॉल साइट क्या करती है पर निर्भर करती है:

trait Foo {
    fn foo(&self) { self.bar() }
    fn bar(&self);
}

struct A;
impl Foo for A {
    fn bar(&self) {} // not recursive
}
struct B;
impl Foo for B {
    fn bar(&self) { self.foo() } // recursive
}

fn main() {
    let a = A;
    a.bar(); // Ok - no @llvm.sideeffect needed anywhere
    let b = B;
    b.bar(); // We need @llvm.sideeffect on this call site
    let c: &[&dyn Foo] = &[&a, &b];
    for i in c {
        i.bar(); // We need @lvm.sideeffect here too
    }
}

AFAICT, हमें कार्यों को हटाने के लिए @llvm.sideeffect अंदर रखना होगा ताकि उन्हें दूर किया जा सके, इसलिए भले ही ये "अनुकूलन" इसके लायक थे, मुझे नहीं लगता कि वे वर्तमान मॉडल के साथ करने के लिए सीधे हैं। अगर वे होते, तो भी ये अनुकूलन यह साबित करने में सक्षम होते कि कोई पुनरावृत्ति नहीं है।

gnzlbg 1 अक्तू॰ 2018

क्या आपने डिबग मोड में प्रयास किया था? (मैं मज़बूती से अपनी मशीनों और खेल के मैदान में डिबग मोड में स्टैक ओवरफ़्लो को पुन: उत्पन्न कर सकता हूं, इसलिए शायद आपको बग को भरने की ज़रूरत है यदि आपके लिए यह मामला नहीं है)

ज़रूर, लेकिन डीबग मोड में एलएलवीएम लूप ऑप्टिमाइज़ेशन नहीं करता है, इसलिए कोई समस्या नहीं है।

यदि प्रोग्राम डिबग मोड में स्टैकओवरफ्लो करता है, तो उसे यूबी बनाने के लिए एलएलवीएम लाइसेंस नहीं देना चाहिए। समस्या यह पता लगा रही है कि क्या अंतिम कार्यक्रम में यूबी है, और आईआर में घूरने से मैं नहीं बता सकता। यह segfaults, लेकिन मुझे नहीं पता कि क्यों। लेकिन यह मुझे लगता है कि एक segfaults में एक stackoverflowing कार्यक्रम "अनुकूलन" करने के लिए एक बग की तरह लगता है।

RalfJung 1 अक्तू॰ 2018

यदि प्रोग्राम डिबग मोड में स्टैकओवरफ्लो करता है, तो उसे यूबी बनाने के लिए एलएलवीएम लाइसेंस नहीं देना चाहिए।
लेकिन यह मुझे लगता है कि एक segfaults में एक stackoverflowing कार्यक्रम "अनुकूलन" करने के लिए एक बग की तरह लगता है।

सी में, निष्पादन के एक धागे को समाप्त करने के लिए माना जाता है, वाष्पशील मेमोरी एक्सेस, I / O, या एक सिंक्रनाइज़िंग परमाणु ऑपरेशन करते हैं। यह मेरे लिए आश्चर्य की बात होगी अगर LLVM-IR दुर्घटना या डिजाइन द्वारा समान शब्दार्थ होने के लिए विकसित नहीं हुआ।

रस्ट कोड में निष्पादन का एक धागा होता है जो कभी भी समाप्त नहीं होता है, और इसके लिए आवश्यक कोई भी ऑपरेशन नहीं करता है जो कि यूबी में नहीं होना चाहिए। मुझे संदेह है कि हम वही एलएलवीएम-आईआर उत्पन्न करते हैं जो अपरिभाषित व्यवहार के साथ एक सी प्रोग्राम करता है। , इसलिए मुझे नहीं लगता कि यह आश्चर्यजनक है कि एलएलवीएम इस रस्ट प्रोग्राम को गलत तरीके से अपना रहा है।

यह segfaults, लेकिन मुझे नहीं पता कि क्यों।

LLVM अनंत पुनरावृत्ति को हटाता है, इसलिए @SergioBenitez जैसा कि ऊपर बताया गया है, कार्यक्रम तब आगे बढ़ता है:

एक यादृच्छिक स्मृति स्थान के संदर्भ को निर्माण करने की अनुमति दी गई थी, और संदर्भ को बाद में पढ़ा गया था।

कार्यक्रम का हिस्सा जो यह करता है वह यह है:

let x = Container::from("hello");  // invalid reference created here
println!("{} {}", x.string, x.num);  // invalid reference dereferenced here

जहाँ Container::from एक अनंत पुनरावृत्ति शुरू करता है, जो एलएलवीएम निष्कर्ष निकालता है वह कभी भी नहीं हो सकता है, और कुछ यादृच्छिक मूल्य के साथ बदल देता है, जो तब निष्क्रिय हो जाता है। : आप कई तरीकों से यह यहाँ misoptimized हो जाता है में से एक को देख सकते हैं https://rust.godbolt.org/z/P7Snex (खेल का मैदान पर https://play.rust-lang.org/?gist=f00d41cc189f9f6897d429350f3781ec&version=stable&mode = रिलीज़ और संस्करण = 2015) किसी को इस अनुकूलन के कारण डिबग बिल्ड से रिलीज़ में एक अलग ही दहशत मिलती है, लेकिन UB UB है।

gnzlbg 1 अक्तू॰ 2018

रस्ट कोड में निष्पादन का एक धागा होता है जो कभी भी समाप्त नहीं होता है, और इसके लिए आवश्यक कोई भी ऑपरेशन नहीं करता है जो कि यूबी में नहीं होना चाहिए। मुझे संदेह है कि हम वही एलएलवीएम-आईआर उत्पन्न करते हैं जो अपरिभाषित व्यवहार के साथ एक सी प्रोग्राम करता है। , इसलिए मुझे नहीं लगता कि यह आश्चर्यजनक है कि एलएलवीएम इस रस्ट प्रोग्राम को गलत तरीके से अपना रहा है।

मैं इस धारणा के अधीन था कि आपने ऊपर तर्क दिया था कि यह अनंत लूप मुद्दे के समान बग नहीं है। ऐसा लगता है कि मैंने आपके संदेशों को तब गलत समझा। गलतफहमी के लिए खेद है।

तो, ऐसा लगता है कि एक अच्छा अगला कदम हमारे द्वारा उत्पन्न आईआर में कुछ llvm.sideffect छिड़कना होगा, और कुछ बेंचमार्क होंगे?

सी में, निष्पादन के एक धागे को समाप्त करने के लिए माना जाता है, वाष्पशील मेमोरी एक्सेस, I / O, या एक सिंक्रनाइज़िंग परमाणु ऑपरेशन करते हैं।

Btw, यह पूरी तरह सही नहीं है - (जैसे एक निरंतर सशर्त साथ एक पाश while (true) { /* ... */ } ) स्पष्ट रूप से, मानक द्वारा अनुमति दी है, भले ही वह किसी भी दुष्प्रभाव नहीं है। यह C ++ में अलग है। एलएलवीएम सी मानक को यहां सही ढंग से लागू नहीं करता है।

RalfJung 1 अक्तू॰ 2018

मैं इस धारणा के अधीन था कि आपने ऊपर तर्क दिया था कि यह अनंत लूप मुद्दे के समान बग नहीं है।

नॉन-टर्मिनेटिंग रस्ट प्रोग्राम्स के व्यवहार को हमेशा परिभाषित किया जाता है, जबकि गैर-टर्मिनेटिंग LLVM-IR प्रोग्राम्स के व्यवहार को केवल तभी परिभाषित किया जाता है जब कुछ शर्तों को पूरा किया जाता है।

मुझे लगा कि यह मुद्दा अनंत छोरों के लिए जंग के कार्यान्वयन को ठीक करने के बारे में है, ताकि उत्पन्न एलएलवीएम-आईआर का व्यवहार परिभाषित हो जाए, और इसके लिए, @llvm.sideeffect , एक बहुत अच्छा समाधान की तरह लग रहा था।

@SergioBenitez ने उल्लेख किया कि कोई भी पुनरावर्तन का उपयोग करके गैर- समाप्तिकारी रस्ट प्रोग्राम बना सकता है, और

मैं इस बात से असहमत नहीं हूं कि ये दो मुद्दे संबंधित हैं, या यहां तक कि वे एक ही बग हैं, लेकिन मेरे लिए, ये दो मुद्दे थोड़े अलग हैं:

वार वार, हम हर एक जंग समारोह में इसे लागू करने के लिए विशेष रूप से गैर-समाप्ति छोरों के लिए एक अनुकूलन बाधा ( @llvm.sideeffect ) लगाने से जाते हैं।
मूल्य-वार, अनंत loop s उपयोगी हैं क्योंकि कार्यक्रम कभी समाप्त नहीं होता है। अनंत पुनरावृत्ति के लिए, क्या कार्यक्रम समाप्त होता है, अनुकूलन स्तर पर निर्भर करता है (जैसे कि एलएलवीएम पुनरावृत्ति को लूप में बदलता है या नहीं), और कब और कैसे कार्यक्रम समाप्त होता है, यह प्लेटफॉर्म (स्टैक आकार, संरक्षित गार्ड पृष्ठ, आदि) पर निर्भर करता है। रस्ट कार्यान्वयन ध्वनि बनाने के लिए दोनों को ठीक करना आवश्यक है, लेकिन अनंत पुनरावृत्ति की स्थिति के लिए, यदि उपयोगकर्ता ने अपने कार्यक्रम को हमेशा के लिए फिर से शुरू करने का इरादा किया है, तो ध्वनि कार्यान्वयन अभी भी "गलत" होगा इस अर्थ में कि यह हमेशा हमेशा के लिए नहीं होगा।

gnzlbg 1 अक्तू॰ 2018

वार वार, हम हर एक जंग समारोह में इसे लागू करने के लिए विशेष रूप से गैर-समाप्ति छोरों के लिए एक अनुकूलन बाधा (@ llvm.sideeffect) को लागू करने से जाते हैं।

विश्लेषण यह दिखाने के लिए आवश्यक है कि एक लूप बॉडी में वास्तव में साइड इफेक्ट्स होते हैं (न कि केवल संभावित रूप से, बाहरी कार्यों के लिए कॉल के रूप में) और इस तरह llvm.sideeffect आवश्यकता नहीं होती है llvm.sideeffect डालेंगे। बेशक, ऐसे कुछ कार्य हैं जिनमें लूप शामिल नहीं हैं, लेकिन यह अभी भी मुझे गुणात्मक अंतर की तरह नहीं लगता है।

hanna-kruppe 1 अक्तू॰ 2018

यदि मैं समस्या को सही ढंग से समझता हूं, तो अनंत-लूप के मामले को ठीक करने के लिए, llvm.sideeffect को loop { ... } और while <compile-time constant true> { ... } सम्मिलित करने के लिए पर्याप्त होना चाहिए जहां लूप के शरीर में कोई break नहीं है

मैं नहीं जानता कि अनंत पुनरावृत्ति के बारे में क्या करना है, लेकिन मैं राल्फजंग से सहमत हूं कि एक असंबंधित सीगफॉल्ट में अनंत पुनरावृत्ति का अनुकूलन वांछनीय व्यवहार नहीं है।

zackw 1 अक्तू॰ 2018

@zackw

यदि मैं समस्या को सही ढंग से समझता हूं, तो अनंत-लूप केस को ठीक करने के लिए, यह llvm.sideeffect को लूप {...} और जबकि में डालने के लिए पर्याप्त होना चाहिए{...} जहां लूप के शरीर में कोई विराम भाव नहीं होता है।

मुझे नहीं लगता कि यह इतना सरल है, loop { if false { break; } } एक अनंत लूप है जिसमें break अभिव्यक्ति शामिल है, फिर भी हमें llvm को हटाने से रोकने के लिए @llvm.sideeffect सम्मिलित करने की आवश्यकता है। AFAICT में हमें @llvm.sideeffect डालना होगा जब तक कि हम यह साबित नहीं कर सकते कि लूप हमेशा समाप्त हो जाता है।

gnzlbg 1 अक्तू॰ 2018

@gnzlbg

loop { if false { break; } } एक अनंत लूप है जिसमें विराम अभिव्यक्ति होती है, फिर भी हमें llvm को हटाने से रोकने के लिए @llvm.sideeffect सम्मिलित करने की आवश्यकता है।

हम्म, हाँ, यह परेशानी है। लेकिन हमें _perfect_ होना जरूरी नहीं है, बस रूढ़िवादी रूप से सही है। एक पाश की तरह

while spinlock.load(Ordering::SeqCst) != 0 {}

( std::sync::atomic प्रलेखन से) आसानी से @llvm.sideeffect आवश्यकता नहीं देखी जाएगी, क्योंकि नियंत्रित स्थिति स्थिर नहीं है (और परमाणु भार ऑपरेशन में LLVM प्रयोजनों के लिए एक साइड-इफेक्ट के रूप में बेहतर गणना थी , या हमारे पास बड़ी समस्याएं हैं)। एक प्रोग्राम जनरेटर द्वारा उत्सर्जित होने वाले परिमित पाश की तरह,

loop {
    if /* runtime-variable condition */ { break }
    /* more stuff */
}

भी परेशानी नहीं होनी चाहिए। वास्तव में, क्या ऐसा कोई मामला है कि "लूप के शरीर में कोई विराम के भाव" नियम गलत हो जाता है _ _

loop {
    if /* provably false at compile time */ { break }
}

?

zackw 1 अक्तू॰ 2018

मैंने सोचा था कि यह मुद्दा अनंत छोरों के लिए जंग के कार्यान्वयन को ठीक करने के बारे में है, ताकि उत्पन्न एलएलवीएम-आईआर का व्यवहार परिभाषित हो जाए, और इसके लिए, @ llvm.sideeffect, एक बहुत अच्छा समाधान की तरह लग रहा था।

काफी उचित। हालाँकि, जैसा कि आपने कहा, मुद्दा (रस्ट सेमेंटिक्स और एलएलवीएम शब्दार्थ के बीच बेमेल) वास्तव में गैर-समाप्ति के बारे में है, न कि लूप के बारे में। इसलिए मुझे लगता है कि हमें यहाँ नज़र रखना चाहिए।

@zackw

यदि मैं समस्या को सही ढंग से समझता हूं, तो अनंत-लूप केस को ठीक करने के लिए, यह llvm.sideeffect को लूप {...} और जबकि में डालने के लिए पर्याप्त होना चाहिए{...} जहां लूप के शरीर में कोई विराम भाव नहीं होता है। यह अनंत छोरों के लिए C ++ शब्दार्थ और रुस्त शब्दार्थ के बीच अंतर को पकड़ता है: जंग में, C ++ के विपरीत, संकलक को यह मानने की अनुमति नहीं है कि एक लूप समाप्त हो जाता है जब यह संकलन समय पर पता चलता है कि यह नहीं है। (मुझे यकीन नहीं है कि छोरों के चेहरे की शुद्धता के बारे में हमें कितनी चिंता करने की ज़रूरत है जहां शरीर घबरा सकता है, लेकिन बाद में इसमें सुधार नहीं किया जा सकता है।)

सी। रस्ट के लिए आप जो भी वर्णन करते हैं, वह किसी भी लूप को मोड़ने की अनुमति देता है। बाकी सब बस करने के लिए निराधार होगा।

इसलिए, उदाहरण के लिए

while test_fermats_last_theorem_on_some_random_number() { }

जंग में एक ठीक कार्यक्रम है (लेकिन न तो C और न ही C ++ में), और यह एक साइड-इफ़ेक्ट के बिना हमेशा के लिए लूप करेगा। इसलिए, यह सभी छोरों का होना है, केवल उन लोगों को छोड़कर जो हम साबित कर सकते हैं कि समाप्त हो जाएंगे।

RalfJung 1 अक्तू॰ 2018

👍1

@zackw

क्या कोई ऐसा मामला है कि "लूप के शरीर में कोई ब्रेक एक्सप्रेशन" नियम इसके अलावा गलत हो जाता है

यह न केवल if /*compile-time condition */ । सभी नियंत्रण-प्रवाह प्रभावित होते हैं ( while , match , for , ...) और रन-टाइम की स्थिति भी प्रभावित होती है।

लेकिन हमें सही, रूढ़िवादी रूप से सही होने की जरूरत नहीं है।

विचार करें:

fn foo(x: bool) { loop { if x { break; } } }

जहां x एक रन-टाइम स्थिति है। अगर हम यहाँ @llvm.sideeffect उत्सर्जन नहीं करते हैं, तो यदि उपयोगकर्ता foo(false) कहीं लिखता है, तो foo को झुकाया जा सकता है और निरंतर प्रचार और मृत कोड उन्मूलन के साथ, लूप को एक में अनुकूलित किया जाता है। साइड इफेक्ट्स के बिना अनंत लूप, जिसके परिणामस्वरूप गलत अनुकूलन होता है।

अगर यह समझ में आता है, एक परिवर्तन जो LLVM को करने की अनुमति होगी foo foo_opt साथ प्रतिस्थापित कर रहा है:

fn foo_opt(x: bool) { if x { foo(true) } else { foo(false) } }

जहाँ दोनों शाखाएँ स्वतंत्र रूप से अनुकूलित होती हैं, और यदि हम @llvm.sideeffect उपयोग नहीं करते हैं तो दूसरी शाखा को गलत तरीके से अनुकूलित किया जाएगा।

यही है, @llvm.sideeffect को छोड़ने में सक्षम होने के लिए, हमें यह साबित करने की आवश्यकता होगी कि LLVM किसी भी परिस्थिति में उस लूप का गलत अनुकूलन नहीं कर सकता है। यह साबित करने का एकमात्र तरीका या तो यह साबित करना है कि लूप हमेशा समाप्त हो जाता है, या यह साबित करने के लिए कि यदि यह समाप्त नहीं होता है, तो यह बिना शर्त उन चीजों में से एक करता है जो गलत-अनुकूलन को रोकते हैं। फिर भी, लूप बंटवारे / छीलने जैसे अनुकूलन एक लूप को छोरों की एक श्रृंखला में बदल सकते हैं, और उनमें से एक होने के लिए गलत अनुकूलन के लिए @llvm.sideeffect नहीं होना पर्याप्त होगा।

gnzlbg 1 अक्तू॰ 2018

इस बग के बारे में सब कुछ मुझे लगता है जैसे यह एलएलवीएम से rustc से हल करना बहुत आसान होगा। (अस्वीकरण: मैं वास्तव में इन परियोजनाओं में से किसी का कोड आधार नहीं जानता)

जैसा कि मैं इसे समझता हूं, LLVM से फिक्सिंग अनुकूलन को चालू करने से बदल रहा होगा (गैर-समाप्ति साबित करें) या तो साबित नहीं हो सकता है) केवल चलाने के लिए जब गैर-समाप्ति साबित हो सकती है (या इसके विपरीत)। मैं यह नहीं कह रहा हूं कि यह आसान (किसी भी तरह से) है, लेकिन एलएलवीएम पहले से ही (मुझे लगता है) लूप को साबित करने (गैर-) को समाप्त करने की कोशिश करने के लिए कोड शामिल है।

दूसरी ओर, rustc केवल ऐसा करने से @llvm.sideeffect , जो संभावित रूप से गैर-समाप्ति के अनुचित उपयोग को अनुकूलित करने वाले अनुकूलन को "सिर्फ" से अधिक प्रभावित करेगा। और rustc को लूप का पता लगाने (गैर-) को समाप्त करने की कोशिश करने के लिए नया कोड एम्बेड करना होगा।

इसलिए मुझे लगता है कि आगे का रास्ता होगा:

प्रत्येक लूप पर @llvm.sideeffect जोड़ें और समस्या को ठीक करने के लिए फ़ंक्शन कॉल करें
एलएलवीएम को गैर-समाप्ति वाले छोरों पर गलत अनुकूलन नहीं करने के लिए ठीक करें, और @llvm.sideeffects हटा दें

आप इस बारे में क्या सोचते हैं? मुझे उम्मीद है कि चरण 1 का प्रदर्शन प्रभाव बहुत भयानक नहीं होगा, हालांकि, भले ही यह 2 बार लागू होने के बाद गायब हो जाए ...

Ekleog 1 अक्तू॰ 2018

👍2

@Ekleog कि @sunfishcode दूसरी पैच के बारे में क्या हो सकता है: https://lists.llvm.org/pipermail/llvm-dev/2017-October/118595.html

फ़ंक्शन विशेषता प्रस्ताव का हिस्सा है
एलएलवीएम आईआर के डिफ़ॉल्ट शब्दार्थ को बदलने के लिए परिभाषित व्यवहार है
अनंत लूप, और फिर संभावित-यूबी में एक विशेषता जोड़ते हैं। इसलिए
अगर हम ऐसा करते हैं, तो @ llvm.sideeffect की भूमिका थोड़ी बन जाती है
सूक्ष्म - यह सी की तरह एक भाषा के लिए एक दृश्य के लिए एक रास्ता होगा
एक समारोह के लिए संभावित-यूबी में, लेकिन फिर व्यक्तिगत के लिए चुनते हैं
उस फ़ंक्शन में लूप्स।

gnzlbg 1 अक्तू॰ 2018

LLVM के लिए निष्पक्ष होने के लिए, संकलक लेखकों ने इस विषय को "मैं एक अनुकूलन लिखने जा रहा हूं जो लूप को गैर-समाप्तिकारी साबित कर रहा है, के दृष्टिकोण से संपर्क नहीं करता है, ताकि मैं उन्हें दूर तक अनुकूलित कर सकूं!" इसके बजाय, यह धारणा कि लूप या तो समाप्त हो जाएंगे या साइड इफेक्ट हो जाएंगे, स्वाभाविक रूप से कुछ सामान्य संकलक एल्गोरिदम में स्वाभाविक रूप से उत्पन्न होते हैं। इसे ठीक करना मौजूदा कोड के लिए सिर्फ एक ट्वीक नहीं है; इसे नई जटिलता की एक महत्वपूर्ण राशि की आवश्यकता होगी।

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

यह तय करने योग्य है। अगर किसी और को इस पर ध्यान देने में दिलचस्पी है, तो मेरा मूल विचार "वास्तविक प्रभाव है" की स्वतंत्र अवधारणाओं में "साइड इफेक्ट्स" की अवधारणा को विभाजित करना है और "गैर-समाप्ति हो सकती है"। और फिर पूरे ऑप्टिमाइज़र के माध्यम से जाएं और उन सभी स्थानों को ढूंढें जो "साइड इफेक्ट्स" के बारे में परवाह करते हैं और यह पता लगाते हैं कि उन्हें वास्तव में किस अवधारणा की आवश्यकता है। और फिर शाखाओं को मेटाडेटा जोड़ने के लिए लूप पास सिखाते हैं जो एक लूप का हिस्सा नहीं हैं, या लूप्स वे अस्थायी रूप से परिमित हैं, ताकि निराशावाद से बचा जा सके।

जब उपयोगकर्ता वास्तव में एक खाली loop { } (या इसी तरह) या बिना शर्त पुनरावर्तन (जो पहले से ही एक लिंट है) को लिखने के लिए संभव समझौता @ llvm.sideeffect सम्मिलित करना हो सकता है। यह समझौता उन लोगों को अनुमति देगा जो वास्तव में इसे प्राप्त करने के लिए एक अनंत प्रभावहीन कताई लूप का इरादा रखते हैं, जबकि बाकी सभी के लिए किसी भी उपरि से परहेज करते हैं। बेशक, यह समझौता सुरक्षित कोड को क्रैश करना असंभव नहीं होगा, लेकिन यह संभवतः गलती से होने की संभावना को कम कर देगा, और ऐसा लगता है कि इसे लागू करना आसान होना चाहिए।

sunfishcode 2 अक्तू॰ 2018

👍8 👎2

इसके बजाय, यह धारणा कि लूप या तो समाप्त हो जाएंगे या साइड इफेक्ट हो जाएंगे, स्वाभाविक रूप से कुछ सामान्य संकलक एल्गोरिदम में स्वाभाविक रूप से उत्पन्न होते हैं।

यह पूरी तरह से अस्वाभाविक है हालांकि अगर आप भी उन परिवर्तनों की शुद्धता के बारे में सोचना शुरू करते हैं। स्पष्ट रूप से, मुझे अभी भी लगता है कि इस धारणा को कभी भी अनुमति देने के लिए सी की एक बड़ी गलती थी, लेकिन अच्छी तरह से।

यदि शरीर में किसी भी निर्देश के संभावित दुष्प्रभाव हैं, तो फ़ंक्शन शरीर पर दुष्प्रभाव हो सकते हैं।

एक अच्छा कारण है कि "गैर-समाप्ति" को आमतौर पर एक प्रभाव माना जाता है जब आप औपचारिक रूप से चीजों को देखना शुरू करते हैं। (हास्केल शुद्ध नहीं है, इसके दो प्रभाव हैं: गैर-समाप्ति और अपवाद।)

उपयोगकर्ता द्वारा शाब्दिक रूप से खाली लूप {} (या समान) या बिना शर्त पुनरावर्तन (जिसमें पहले से ही एक लिंट होता है) लिखने पर संभावित समझौता @ llvm.sideeffect सम्मिलित करना हो सकता है। यह समझौता उन लोगों को अनुमति देगा जो वास्तव में इसे प्राप्त करने के लिए एक अनंत प्रभावहीन कताई लूप का इरादा रखते हैं, जबकि बाकी सभी के लिए किसी भी उपरि से परहेज करते हैं। बेशक, यह समझौता सुरक्षित कोड को क्रैश करना असंभव नहीं होगा, लेकिन यह संभवतः गलती से होने की संभावना को कम कर देगा, और ऐसा लगता है कि इसे लागू करना आसान होना चाहिए।

जैसा कि आपने खुद बताया, यह अभी भी गलत है। मुझे नहीं लगता कि हमें एक "समाधान" को स्वीकार करना चाहिए जिसे हम गलत होना जानते हैं । कंपाइलर हमारे बुनियादी ढांचे का एक अभिन्न हिस्सा हैं, हमें सिर्फ यह उम्मीद नहीं करनी चाहिए कि कुछ भी गलत न हो। यह ठोस आधार बनाने का कोई तरीका नहीं है।

यहाँ क्या हुआ है कि "संकलक क्या चाहते हैं " के साथ शुरू करने के बजाय, क्या संकलक के आसपास शुद्धता की धारणा का निर्माण किया गया था और फिर उनके विनिर्देशन बना रहे थे। एक सही संकलक एक प्रोग्राम को चालू नहीं करता है जो हमेशा एक में बदल जाता है जो समाप्त होता है, अवधि। मुझे यह स्पष्ट रूप से स्पष्ट लगता है, लेकिन रस्ट के पास एक उचित प्रकार की प्रणाली है, यह स्पष्ट रूप से प्रकारों में देखा जाता है, यही कारण है कि मुद्दा नियमित रूप से सामने आ रहा है।

जिन बाधाओं के साथ हम काम कर रहे हैं, उन्हें देखते हुए (अर्थात्, एलएलवीएम), हमें जो करना चाहिए वह पर्याप्त स्थानों में llvm.sideeffect जोड़कर शुरू होता है, ताकि हर डायवर्जन निष्पादन की गारंटी "निष्पादित" हो जाए। तब हम एक उचित (जैसे, ध्वनि और सही) आधार रेखा पर पहुंच गए हैं और इन एनोटेशन को हटाने के तरीके में सुधार के बारे में बात कर सकते हैं जब हम गारंटी दे सकते हैं कि उनकी आवश्यकता नहीं है।

RalfJung 2 अक्तू॰ 2018

👍9 👎1

अपनी बात को और सटीक बनाने के लिए, मुझे लगता है कि निम्नलिखित एक ध्वनि जंग टोकरा है, जिसमें pick_a_number_greater_2 रिटर्निंग (गैर-नियतात्मक रूप से) किसी प्रकार का बड़ा-इंट:

fn test_fermats_last_theorem() -> bool {
  let x = pick_a_number_greater_2();
  let y = pick_a_number_greater_2();
  let z = pick_a_number_greater_2();
  let n = pick_a_number_greater_2();
  // x^n + y^n = z^n is impossible for n > 2
  pow(x, n) + pow(y, n) != pow(z, n)
}

pub fn diverge() -> ! {
  while test_fermats_last_theorem() { }
  // This code is unreachable, as proven by Andrew Wiles
  unsafe { mem::transmute(()) }
}

यदि हम उस डायवर्जन लूप को संकलित करते हैं, तो यह एक बग है और इसे ठीक किया जाना चाहिए।

इस भोलेपन को ठीक करने में कितना प्रदर्शन होगा, इसके लिए हमारे पास अब तक संख्या नहीं है। जब तक हम ऐसा नहीं करते, मुझे उपरोक्त जैसे कार्यक्रमों को जानबूझकर तोड़ने का कोई कारण नहीं दिखता।

RalfJung 2 अक्तू॰ 2018

👍4 😕1

व्यवहार में, fn foo() { foo() } हमेशा संसाधन थकावट के कारण समाप्त हो जाएंगे, लेकिन चूंकि रस्ट एब्सट्रैक्ट मशीन में एक असीम रूप से बड़ी स्टैक फ्रेम (AFAIK) है, इसलिए यह उस कोड को fn foo() { loop {} } में बदलने के लिए वैध है जो कभी नहीं होगा समाप्त (या बहुत बाद में, जब ब्रह्मांड जम जाता है)। क्या यह परिवर्तन मान्य होना चाहिए? मैं कहूंगा कि हां, अन्यथा हम टेल-कॉल अनुकूलन नहीं कर सकते हैं जब तक कि हम समाप्ति को साबित नहीं कर सकते, जो दुर्भाग्यपूर्ण होगा।

क्या यह समझ में आएगा कि एक unsafe आंतरिक है जो बताता है कि एक दिया हुआ लूप, पुनरावृत्ति, ... समाप्त हो गया है? N1528 एक उदाहरण देता है, अगर लूप्स को समाप्त करने के लिए नहीं माना जा सकता है, तो लूप संलयन को लिस्ट कोड ट्रैवर्सिंग लिंक सूचियों पर लागू नहीं किया जा सकता है, क्योंकि लिंक की गई सूची परिपत्र हो सकती है, और यह साबित करना कि लिंक की गई सूची परिपत्र नहीं है - आधुनिक कंपाइलर कुछ नहीं हो सकता है कर।

gnzlbg 2 अक्तू॰ 2018

👍4 ❤2

मैं पूरी तरह सहमत हूं कि हमें अच्छे के लिए इस ध्वनि मुद्दे को ठीक करने की आवश्यकता है। हालांकि, जिस तरह से हम इस बारे में जाने की संभावना को ध्यान में रखना चाहिए कि " llvm.sideeffect हर जगह हम इसे अनावश्यक साबित नहीं कर सकते हैं" उन कार्यक्रमों की कोड गुणवत्ता को पुनः प्राप्त कर सकते हैं जो आज सही ढंग से संकलित हैं। हालांकि इस तरह की चिंताओं को ध्वनि संकलक होने की आवश्यकता के कारण समाप्त कर दिया जाता है, यह इस तरह से आगे बढ़ने के लिए विवेकपूर्ण हो सकता है कि प्रदर्शन के प्रतिगमन से बचने और औसत रूप में औसत रस्ट प्रोग्रामर के लिए जीवन की गुणवत्ता में सुधार के लिए उचित फिक्स में थोड़ी देरी करता है। समय। मैंने प्रस्ताव रखा है:

लंबे समय से चली आ रही ध्वनि बग (# 10184) के लिए अन्य संभावित-परफॉर्मेंस-रिग्रेसिंग फ़िक्सेस के साथ, हमें एक -Z फ़्लैग के पीछे के फिक्स को लागू करना चाहिए, ताकि जंगली में कोड बेस पर प्रदर्शन प्रभाव का मूल्यांकन किया जा सके।
यदि प्रभाव विक्षिप्त हो जाता है, महान, हम बस डिफ़ॉल्ट रूप से ठीक कर सकते हैं।
लेकिन अगर इससे वास्तविक प्रतिगमन होते हैं, तो हम उस डेटा को LLVM लोगों तक ले जा सकते हैं और पहले LLVM को बेहतर बनाने का प्रयास कर सकते हैं (या हम प्रतिगमन को खाने के लिए चुन सकते हैं और बाद में इसे ठीक कर सकते हैं, लेकिन किसी भी मामले में हम एक सूचित निर्णय लेंगे)
यदि हम रिग्रेसन के कारण डिफ़ॉल्ट रूप से फिक्स को चालू नहीं करने का निर्णय लेते हैं, तो हम कम से कम llvm.sideeffect को सिंटैक्टिक रूप से खाली छोरों को जोड़कर आगे बढ़ सकते हैं: वे बल्कि आम हैं और उन्हें गलत तरीके से इस्तेमाल करने से कई लोग गलत तरीके से खर्च कर रहे हैं। घंटों डिबगिंग अजीब मुद्दों (# 38136, # 47537, # 54214, और निश्चित रूप से वहाँ अधिक है), इसलिए भले ही इस शमन ध्वनि बग पर कोई असर नहीं पड़ता है, यह डेवलपर्स के लिए एक ठोस लाभ होगा जब हम उचित में काम करते हैं बग ठीक करें।

जाहिर है, इस परिप्रेक्ष्य को इस तथ्य से सूचित किया जाता है कि यह मुद्दा वर्षों से खड़ा है। यदि यह एक ताजा प्रतिगमन था, तो मैं इसे और अधिक तेज़ी से ठीक करने या पीआर को पुनः प्रस्तुत करने के लिए अधिक खुला होगा जो इसे पेश करता है।

hanna-kruppe 2 अक्तू॰ 2018

👍12

इस बीच, https://doc.rust-lang.org/beta/reference/behavior-considered-undefined.html में इसका उल्लेख होना चाहिए जब तक यह मुद्दा खुला है?

NeoLegends 4 जन॰ 2019

क्या यह समझ में आएगा कि एक unsafe आंतरिक है जो बताता है कि एक दिया हुआ लूप, पुनरावृत्ति, ... समाप्त हो गया है?

std::hint::reachable_unchecked ?

Vurich 8 मई 2019

😄8

संयोग से मैं एक टीसीपी संदेश प्रणाली के लिए इस वास्तविक कोड में भाग गया। मेरे पास एक स्टॉपगैप के रूप में एक अनंत लूप था जब तक कि मैं रोकने के लिए एक वास्तविक तंत्र में नहीं डालता लेकिन धागा तुरंत बाहर निकल गया।

rsimmonsjr 26 अग॰ 2019

😕2

मामले में कोई भी टेस्ट केस कोड गोल्फ खेलना चाहता था:

fn main() {
    (|| loop {})()
}

`` `
$ कार्गो रन --release
अवैध निर्देश (कोर डंप)

ExpHP 17 सित॰ 2019

👍16 👀13

मामले में कोई भी टेस्ट केस कोड गोल्फ खेलना चाहता था:
pub fn main() {
   (|| loop {})()
}

Https://github.com/rust-lang/rust/pull/59546 में -Z insert-sideeffect जंग वाला झंडा, यह लूप करता रहता है :)

इससे पहले:

main:
  ud2

उपरांत:

main:
.LBB0_1:
  jmp .LBB0_1

memoryruins 15 अक्तू॰ 2019

👍9 🚀5 😄2

वैसे, एलएलवीएम बग ट्रैकिंग यह https://bugs.llvm.org/show_bug.cgi?id=965 है , जिसे मैंने इस थ्रेड में अभी तक पोस्ट नहीं किया है।

bstrie 21 अक्तू॰ 2019

👍3

जो मैंने अभी तक इस धागे में पोस्ट नहीं देखा है।

https://github.com/rust-lang/rust/issues/28728#issuecomment -331460667 और https://github.com/rust-lang/rust/issues/28728#issuecomment -263956134

shepmaster 21 अक्तू॰ 2019

@RalfJung क्या आप हाइपरलिंक https://github.com/simnalamburt/snippets/blob/master/rust/src/bin/infinite.rs को मुद्दे के विवरण में https://github.com/imimnalamburt/snippets/blob पर अपडेट कर सकते हैं rust /

simnalamburt 8 नव॰ 2019

@simnalamburt ने किया, धन्यवाद!

RalfJung 8 नव॰ 2019

MIR ऑप्ट स्तर को बढ़ाने से निम्न मामले में गलत तरीके से बचने से प्रतीत होता है:

pub fn main() {
   (|| loop {})()
}

--emit=llvm-ir -C opt-level=1

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  unreachable
}

--emit=llvm-ir -C opt-level=1 -Z mir-opt-level=2

define void @_ZN7example4main17hf7943ea78b0ea0b0E() unnamed_addr #0 !dbg !6 {
  br label %bb1, !dbg !10

bb1:                                              ; preds = %bb1, %start
  br label %bb1, !dbg !11
}

https://godbolt.org/z/N7VHnj

rustc 1.45.0-nightly (5fd2f06e9 2020-05-31)

memoryruins 3 जून 2020

😕1

pub fn oops() {
   (|| loop {})() 
}

pub fn main() {
   oops()
}

इसने उस विशेष मामले में मदद की लेकिन सामान्य रूप से इस मुद्दे को हल नहीं किया। https://godbolt.org/z/5hv87d

सामान्य तौर पर यह समस्या केवल तब हल की जा सकती है जब किसी प्रासंगिक अनुकूलन का उपयोग करने से पहले रस्ट या एलएलवीएम एक शुद्ध फ़ंक्शन साबित हो सकता है।

nbdd0121 3 जून 2020

वास्तव में, मैं यह दावा नहीं कर रहा था कि इसने इस मुद्दे को हल कर दिया है। सूक्ष्म प्रभाव दूसरों के लिए पर्याप्त दिलचस्प था कि यह यहां भी ध्यान देने योग्य था। -Z insert-sideeffect दोनों मामलों को सही करने के लिए जारी है।

memoryruins 3 जून 2020

एलएलवीएम की ओर कुछ बढ़ रहा है: प्रगति की गारंटी को नियंत्रित करने के लिए एक फ़ंक्शन-स्तरीय विशेषता जोड़ने का प्रस्ताव है। https://reviews.llvm.org/D85393

RalfJung 6 अग॰ 2020

👍1

मुझे यकीन नहीं है कि क्यों हर कोई (यहां और एलएलवीएम थ्रेड्स पर) आगे की प्रगति के बारे में खंड पर जोर दे रहा है।

लूप का उन्मूलन स्मृति मॉडल का प्रत्यक्ष परिणाम प्रतीत होता है: मानों की गणना को तब तक ले जाने की अनुमति होती है, जब तक वे मूल्य के उपयोग से पहले होते हैं। अब, अगर कोई प्रमाण है तो मूल्य का कोई उपयोग नहीं हो सकता है, यह इस बात का प्रमाण है कि ऐसा नहीं होता है-पहले, और कोड को भविष्य में असीम रूप से दूर ले जाया जा सकता है, और फिर भी मेमोरी मॉडल को संतुष्ट कर सकता है।

या, यदि आप स्मृति मॉडल से परिचित नहीं हैं, तो विचार करें कि संपूर्ण लूप एक मान कंप्यूटिंग करने वाले फ़ंक्शन में दूर है। अब उस फ़ंक्शन के कॉल द्वारा लूप के बाहर के सभी रीड्स को प्रतिस्थापित करें। यह परिवर्तन निश्चित रूप से मान्य है। अब, यदि मूल्य का कोई उपयोग नहीं है, तो अनंत लूप करने वाले फ़ंक्शन के कोई भी इनवोकेशन नहीं हैं।

olotenko 8 अग॰ 2020

मूल्यों के अभिकलन को तब तक स्थानांतरित करने की अनुमति दी जाती है, जब तक वे मूल्य के उपयोग से पहले होते हैं। अब, अगर कोई प्रमाण है तो मूल्य का कोई उपयोग नहीं हो सकता है, यह इस बात का प्रमाण है कि ऐसा नहीं होता है-पहले, और कोड को भविष्य में असीम रूप से दूर ले जाया जा सकता है, और फिर भी मेमोरी मॉडल को संतुष्ट कर सकता है।

यह कथन तभी सही है जब उस गणना को समाप्त करने की गारंटी हो। गैर-समाप्ति एक साइड-इफेक्ट है, और जैसे आप एक गणना को नहीं हटा सकते हैं जो स्टडआउट को प्रिंट करता है (यह "शुद्ध नहीं है"), आप एक गणना को नहीं हटा सकते हैं जो समाप्त नहीं करता है।

निम्न फ़ंक्शन कॉल को निकालना ठीक नहीं है, भले ही परिणाम अप्रयुक्त हो:

fn sideeffect() -> u32 {
  println!("Hello!");
  42
}

fn main() {
  let _ = sideffect(); // May not be removed.
}

यह किसी भी प्रकार के साइड-इफेक्ट के लिए सच है, और यह सच है जब आप प्रिंट को loop {} द्वारा प्रतिस्थापित करते हैं।

RalfJung 8 अग॰ 2020

❤4 👍1

साइड-इफ़ेक्ट के रूप में गैर-समाप्ति के बारे में दावे के लिए न केवल एक समझौते की आवश्यकता है कि यह (यह गैर-विवादास्पद है), बल्कि _when_ के बारे में भी एक समझौता होना चाहिए।

यदि लूप मान की गणना करता है, तो गैर-समाप्ति सुनिश्चित है। गैर-समाप्ति नहीं देखी जाती है, यदि आपको उन गणनाओं को फिर से आदेश देने की अनुमति दी जाती है जो लूप के परिणाम पर निर्भर नहीं होती हैं।

एलएलवीएम थ्रेड पर उदाहरण की तरह।

x = y % 42;
if y < 0 return 0;
...

विभाजन की समाप्ति गुणों का पुनर्मूल्यांकन से कोई लेना-देना नहीं है। आधुनिक सीपीयू समानांतर में सफल शाखा के विभाजन, तुलना, शाखा की भविष्यवाणी और प्रीफेटिंग को निष्पादित करने का प्रयास करेंगे। इसलिए, यदि आप 0 वापस लौटाते हैं, तो y निरीक्षण करने पर पूरा होने वाले विभाजन का निरीक्षण करने की गारंटी नहीं है। ("द्वारा" यहां देखें) मेरा मतलब है कि वास्तव में एक ऑसिलोमीटर के साथ माप जहां सीपीयू कार्यक्रम पर नहीं है)

यदि आप पूर्ण किए गए विभाजन का निरीक्षण नहीं कर सकते हैं, तो आप प्रारंभ किए गए विभाजन का निरीक्षण नहीं कर सकते। इसलिए ऊपर दिए गए उदाहरण में विभाजन को आमतौर पर फिर से व्यवस्थित करने की अनुमति दी जाती है, जो एक संकलक कर सकता है:

if y < 0 return 0;
x = y % 42;
...

मैं कहता हूं "आमतौर पर", क्योंकि शायद ऐसी भाषाएं हैं जहां यह अनुमति नहीं है। मुझे नहीं पता कि अगर जंग ऐसी कोई भाषा है।

शुद्ध छोरों अलग नहीं हैं।

मैं यह नहीं कह रहा हूं कि यह कोई समस्या नहीं है। मैं केवल यह कह रहा हूं कि आगे की प्रगति की गारंटी वह चीज नहीं है जो इसे होने देती है।

olotenko 9 अग॰ 2020

साइड-इफ़ेक्ट के रूप में गैर-समाप्ति के बारे में दावे के लिए न केवल एक समझौते की आवश्यकता है कि यह (यह गैर-विवादास्पद है), बल्कि यह भी कि यह कब मनाया जाना चाहिए, इसके बारे में भी एक समझौते पर विचार किया जाना चाहिए।

मैं जो व्यक्त कर रहा हूं वह प्रोग्रामिंग भाषाओं और कंपाइलरों के संपूर्ण अनुसंधान क्षेत्र की सहमति है। निश्चित रूप से आप असहमत हैं, लेकिन तब आप "कंपाइलर शुद्धता" जैसे शब्दों को फिर से परिभाषित कर सकते हैं - यह दूसरों के साथ चर्चा के लिए सहायक नहीं है।

अनुमेय प्रेक्षणों को हमेशा स्रोत स्तर पर परिभाषित किया जाता है। भाषा विनिर्देश एक "सार मशीन" को परिभाषित करता है, जो वर्णन करता है (आदर्श रूप से श्रमसाध्य गणितीय विस्तार में) एक कार्यक्रम के अनुमेय अवलोकन योग्य व्यवहार क्या हैं। यह दस्तावेज़ किसी भी अनुकूलन के बारे में बात नहीं करता है।

एक संकलक की शुद्धता को तब मापा जाता है कि क्या यह प्रोग्राम केवल वे ही देखने योग्य व्यवहार प्रदर्शित करता है जो यह कहता है कि स्रोत कार्यक्रम हो सकता है। यह है कि हर एक प्रोग्रामिंग भाषा जो शुद्धता को गंभीरता से काम करती है, और यह एकमात्र तरीका है जो हम जानते हैं कि एक कंपाइलर सही होने पर सटीक तरीके से कैसे कब्जा किया जाए।

प्रत्येक भाषा पर निर्भर है कि यह परिभाषित किया जाए कि स्रोत स्तर पर वास्तव में क्या अवलोकन योग्य है, और कौन से स्रोत व्यवहार को "अपरिभाषित" माना जाता है और इस प्रकार संकलक द्वारा कभी भी घटित नहीं किया जा सकता है। यह मुद्दा इसलिए उठता है क्योंकि C ++ कहता है कि कोई अन्य दुष्प्रभाव ("मूक विचलन") के साथ एक अनंत लूप अपरिभाषित व्यवहार है, लेकिन रस्ट ऐसा नहीं कहता है। इसका मतलब यह है कि जंग में गैर-समाप्ति हमेशा देखने योग्य है, और संकलक द्वारा संरक्षित किया जाना चाहिए। अधिकांश प्रोग्रामिंग लैंग्वेज इस विकल्प को बनाते हैं, क्योंकि C ++ विकल्प एक कार्यक्रम में गलती से अपरिभाषित व्यवहार (और इस प्रकार महत्वपूर्ण कीड़े) को पेश करना बहुत आसान बना सकता है। रस्ट एक वादा करता है कि सुरक्षित कोड से कोई अपरिभाषित व्यवहार उत्पन्न नहीं हो सकता है, और चूंकि सुरक्षित कोड में अनंत लूप हो सकते हैं, यह निम्नानुसार है कि रस्ट में अनंत लूप को परिभाषित किया जाना चाहिए (और इस प्रकार संरक्षित) व्यवहार।

अगर ये चीजें भ्रामक हैं, तो मैं कुछ पृष्ठभूमि पढ़ने का सुझाव देता हूं। मैं बेंजामिन पियर्स द्वारा "प्रकार और प्रोग्रामिंग भाषा" की सिफारिश कर सकता हूं। आपको संभवतः बहुत सारे ब्लॉग पोस्ट मिलेंगे, हालांकि यह जज करना मुश्किल हो सकता है कि लेखक वास्तव में कितना अच्छा है।

RalfJung 9 अग॰ 2020

❤7 👍4

सुगमता के लिए, यदि आपका विभाजन उदाहरण बदल दिया गया था

x = 42 % y;
if y <= 0 { return 0; }

फिर मुझे आशा है कि आप सहमत होंगे कि सशर्त _cannot_ को विभाजन से ऊपर फहराया जाना चाहिए, क्योंकि जब वे शून्य होते हैं तो अवलोकन योग्य व्यवहार बदल जाएगा (दुर्घटनाग्रस्त होने से शून्य पर लौटने तक)।

उसी तरह, में

x = if y == 0 { loop {} } else { y % 42 };
if y < 0 { return 0; }

जंग अमूर्त मशीन के रूप में यह फिर से लिखा जा करने की अनुमति देता है

if y == 0 { loop {} }
else if y < 0 { return 0; }
x = y % 42;

लेकिन पहली शर्त और लूप को खारिज नहीं किया जा सकता है।

zackw 9 अग॰ 2020

👍1

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

मेरे साथ वहन करने के लिए धन्यवाद

olotenko 10 अग॰ 2020

@zackw धन्यवाद। यह अलग कोड है, जो निश्चित रूप से एक अलग अनुकूलन का परिणाम देगा।

विभाजन के दोष के रूप में उसी तरह से अनुकूलित किए जा रहे छोरों के बारे में मेरा आधार (विभाजन का परिणाम नहीं देख सकता है == लूप को समाप्त नहीं देख सकता है), इसलिए बाकी कोई फर्क नहीं पड़ता।

olotenko 10 अग॰ 2020

@olotenko मुझे नहीं पता कि "लूप परिणाम" देखने से आपका क्या मतलब है। एक गैर-समाप्ति लूप पूरे कार्यक्रम को विचलन बनाता है, जिसे अवलोकनीय व्यवहार माना जाता बाहर अवलोकनीय है। जैसा कि, उपयोगकर्ता प्रोग्राम को चला सकता है और देख सकता है कि यह हमेशा के लिए चला जाता है। एक प्रोग्राम जो हमेशा के लिए चला जाता है, उसे समाप्त होने वाले प्रोग्राम में संकलित नहीं किया जा सकता है, क्योंकि यह वह परिवर्तन है जो उपयोगकर्ता प्रोग्राम के बारे में देख सकता है।

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

एक और उदाहरण देने के लिए:

fn main() {
  loop {}
  println!("Hello");
}

लूप के कारण यह प्रोग्राम कभी भी प्रिंट नहीं करेगा। लेकिन अगर आपने लूप को अनुकूलित किया है (या प्रिंट के साथ लूप को फिर से व्यवस्थित किया है), अचानक प्रोग्राम "हैलो" प्रिंट करेगा। इस प्रकार ये अनुकूलन कार्यक्रम के अवलोकनीय व्यवहार को बदल देते हैं, और अस्वीकृत हो जाते हैं।

RalfJung 10 अग॰ 2020

@ राल्फजंग यह ठीक है, मुझे अब मिल गया है। मेरी मूल समस्या यह थी कि "आगे बढ़ने की गारंटी" की भूमिका यहाँ क्या है। अनुकूलन पूरी तरह से डेटा निर्भरता से संभव है। मेरी गलती यह थी कि वास्तव में डेटा निर्भरता कार्यक्रम के क्रम का हिस्सा नहीं है: यह शाब्दिक रूप से भाषा के शब्दार्थ के अनुसार पूरी तरह से आदेश दिए गए भाव हैं। यदि प्रोग्राम ऑर्डर कुल है, तो फॉरवर्ड प्रोग्रेस गारंटी के बिना (जिसे हम "प्रोग्राम ऑर्डर के किसी भी उप-पथ के रूप में निश्चिंत कर सकते हैं") हम केवल (एक्सप्रेशन ऑर्डर में) रीऑर्डर कर सकते हैं, जिसे हम समाप्त कर सकते हैं (के रूप में) कुछ अन्य गुणों को संरक्षित करना, जैसे कि सिंक्रनाइज़ेशन क्रियाओं का अवलोकन, OS कॉल, IO, आदि)।

मुझे इसके बारे में कुछ और सोचने की जरूरत है, लेकिन मुझे लगता है कि मैं इसका कारण देख सकता हूं कि हम "दिखावा" विभाजन x = y % 42 साथ उदाहरण में हुआ, भले ही यह वास्तव में कुछ इनपुट के लिए निष्पादित न हो, लेकिन वही क्यों मनमाने ढंग से छोरों पर लागू नहीं होता है। मेरा मतलब है, कुल (कार्यक्रम) आदेश और आंशिक (निष्पादन) आदेश के पत्राचार की सूक्ष्मता।

मुझे लगता है कि "अवलोकन योग्य व्यवहार" इससे थोड़ा अधिक सूक्ष्म हो सकता है, क्योंकि एक अनंत पुनरावृत्ति एक स्टैक ओवरफ्लो दुर्घटना ("परिणाम का अवलोकन करने वाले उपयोगकर्ता के अर्थ में" समाप्त हो जाएगा), लेकिन एक पूंछ-कॉल अनुकूलन इसे एक गैर-समाप्ति लूप में बदल देगा। कम से कम यह एक और चीज है जो रस्ट / एलएलवीएम करेगा। लेकिन हमें उस प्रश्न पर चर्चा करने की आवश्यकता नहीं है क्योंकि वास्तव में मेरी समस्या क्या है (जब तक आप नहीं चाहते हैं! मुझे यकीन है कि अगर यह अपेक्षित है तो मुझे खुशी है)।

olotenko 10 अग॰ 2020

स्टैक ओवरफ़्लो

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

हम केवल (अभिव्यक्ति के क्रम में) केवल अभिव्यक्ति को समाप्त कर सकते हैं जिसे हम समापन के रूप में साबित कर सकते हैं

वास्तव में। Morevoer उन्हें "शुद्ध" होना है, अर्थात, साइड-इफ़ेक्ट-फ़्री - आप दो println! फिर से नहीं

डिविज़न भी संभावित रूप से अपवित्र है, लेकिन केवल 0 से विभाजित करते समय - जो एक आतंक का कारण बनता है, अर्थात, एक नियंत्रण प्रभाव। यह प्रत्यक्ष रूप से अवलोकन योग्य नहीं है, लेकिन अप्रत्यक्ष रूप से (जैसे कि पैनिक हैंडलर स्टैडआउट के लिए कुछ प्रिंट करता है, जो बाद में अवलोकन योग्य है)। इस प्रकार विभाजन को केवल हम पुन: व्यवस्थित कर सकते हैं सुनिश्चित करें कि हम 0 से विभाजित नहीं हैं।

RalfJung 10 अग॰ 2020

👍1

मेरा कुछ डेमो कोड है जो मुझे लगता है कि यह मुद्दा हो सकता है लेकिन मैं पूरी तरह से निश्चित नहीं हूं। यदि आवश्यक हो तो मैं इसे एक नई बग रिपोर्ट में डाल सकता हूं।
मैंने इसके लिए एक कोड https://github.com/uglyoldbob/rust_demo पर एक git रेपो में रखा

मेरा अनंत लूप (साइड इफेक्ट्स के साथ) बाहर अनुकूलित है और एक जाल निर्देश उत्पन्न होता है।

uglyoldbob 10 अग॰ 2020

मुझे नहीं पता कि यह इस समस्या का उदाहरण है या कुछ और ... एम्बेडेड डिवाइस मेरी विशेषता बिल्कुल नहीं हैं और इन सभी बाहरी टोकरा निर्भरता के साथ मुझे नहीं पता कि कोड क्या कर रहा है। ^ ^ लेकिन आपका कार्यक्रम है नहीं सुरक्षित है और यह तो मैं कहेंगे यह एक अलग समस्या है, पाश में एक अस्थिर उपयोग कर सकते है नहीं करता है। जब मैं खेल के मैदान पर आपका उदाहरण देता हूं, तो मुझे लगता है कि यह सही तरीके से संकलित है, इसलिए मुझे संदेह है कि समस्या अतिरिक्त निर्भरता में से एक के साथ है।

RalfJung 10 अग॰ 2020

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

olotenko 10 अग॰ 2020

@uglyoldbob वास्तव में आपके उदाहरण में क्या हो रहा है अगर llvm-objdump शानदार रूप से अनहेल्फ़ (और गलत) नहीं हो रहे होते। वह bl #4 (जो वास्तव में मान्य विधानसभा सिंटैक्स नहीं है) यहाँ bl अनुदेश के अंत के बाद 4 बाइट्स शाखा का अर्थ है, main फ़ंक्शन का अंत, उर्फ अगले समारोह की शुरुआत। अगला फ़ंक्शन कहा जाता है (जब मैं इसे बनाता हूं) _ZN11broken_loop18__cortex_m_rt_main17hbe300c9f0053d54dE , और वह आपका वास्तविक main फ़ंक्शन है। Unmangled नाम के साथ समारोह main आपके समारोह नहीं है, लेकिन एक पूरी तरह से अलग समारोह द्वारा उत्पन्न #[entry] मैक्रो द्वारा प्रदान की cortex-m-rt । आपका कोड वास्तव में दूर अनुकूलित नहीं किया जा रहा है। (वास्तव में, जब आप डिबग मोड में निर्माण कर रहे हैं, तब भी अनुकूलक नहीं चल रहा है।)

comex 11 अग॰ 2020

Rust: एलएलवीएम लूप ऑप्टिमाइज़ेशन सुरक्षित कार्यक्रमों को क्रैश बना सकता है

सबसे उपयोगी टिप्पणी

सभी 97 टिप्पणियाँ

प्रत्यावर्तन

लूप

मेटा

संबंधित मुद्दों