Rust: एक बार एलएलवीएम द्वारा उन्हें गलत तरीके से संकलित न करने पर डिफ़ॉल्ट रूप से नोअलिया एनोटेशन को फिर से सक्षम करें

को निर्मित 6 अक्तू॰ 2018 · 33टिप्पणियाँ · स्रोत: rust-lang/rust

यह समस्या LLVM में एक बग के कारण https://github.com/rust-lang/rust/pull/54639 में पेश किए गए -Zmutable-alias=no डिफ़ॉल्ट को पूर्ववत करने को ट्रैक करती है। सीसी @nagisa

( देजा वू? )

A-LLVM A-codegen C-tracking-issue I-slow T-compiler

स्रोत

bstrie

👍43 👀1 🚀1

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

मैंने इसे एक साधारण सी टेस्ट केस में घटा दिया (-O3 और -O0 पर संकलित करें और आउटपुट की तुलना करें):

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

__attribute__((always_inline))
static inline void copy(int *restrict a, int *restrict b) {
    assert(a != b);
    *b = *a;
    *a = 7;
}

__attribute__((noinline))
void floppy(int mat[static 2], size_t idxs[static 3]) {
    for (int i = 0; i < 3; i++) {
        copy(&mat[i%2], &mat[idxs[i]]);
    }
}

int main() {
    int mat[3] = {10, 20};
    size_t idxs[3] = {1, 0, 1};
    floppy(mat, idxs);
    printf("%d %d\n", mat[0], mat[1]);
}

ध्यान दें कि यदि आप restrict , noalias बराबर C को हटाते हैं, तो व्यवहार सही है। फिर भी, assert(a != b) गुजरता है, यह साबित करते हुए कि restrict साथ कॉल करने के कारण कोई यूबी नहीं हो सकता है।

क्या हो रहा है:

copy() इनलाइन हो जाता है, जिसके परिणामस्वरूप कुछ ऐसा होता है:

for (int i = 0; i < 3; i++) {
    mat[idxs[i]] = mat[i%2]; mat[i%2] = 7;
}

LLVM लूप को अनियंत्रित करता है:

mat[idxs[0]] = mat[0]; mat[0] = 7; /* from copy(&mat[0%2], &mat[idxs[0]]) */
mat[idxs[1]] = mat[1]; mat[1] = 7; /* from copy(&mat[1%2], &mat[idxs[1]]) */
mat[idxs[2]] = mat[0]; mat[0] = 7; /* from copy(&mat[2%2], &mat[idxs[2]]) */

एलएलवीएम सोचता है कि mat[0] mat[idxs[1]] या mat[1] साथ उपनाम नहीं हो सकता है, एर्गो इसे mat[0] = 7; और mat[idxs[2]] = mat[0]; बीच बदला नहीं जा सकता है, यह सुरक्षित है बाद वाले को mat[idxs[2]] = 7; अनुकूलित करने के लिए वैश्विक मूल्य क्रमांकन।

लेकिन mat[0] साथ उपनाम करता है mat[idxs[1]] , क्योंकि idxs[1] == 0 । और हमने यह वादा नहीं किया था, क्योंकि दूसरे पुनरावृत्ति पर जब &mat[idxs[1]] को copy , तो दूसरा तर्क &mat[1] । तो LLVM को ऐसा क्यों नहीं लगता?

खैर, इसे copy इनलाइन करने के तरीके से करना है। लोड और स्टोर निर्देशों पर noalias फ़ंक्शन विशेषता !alias.scope और !noalias मेटाडेटा में बदल जाती है, जैसे:

  %8 = load i32, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13
  store i32 %8, i32* %7, align 4, !tbaa !8, !alias.scope !13, !noalias !10
  store i32 7, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13

आम तौर पर, यदि किसी फ़ंक्शन को कई बार इनलाइन किया जाता है, तो प्रत्येक कॉपी को alias.scope और noalias के लिए अपनी विशिष्ट आईडी मिलती है, यह दर्शाता है कि प्रत्येक कॉल noalias ( restrict noalias चिह्नित तर्कों की जोड़ी के बीच अपने स्वयं के 'असमानता' संबंध* का प्रतिनिधित्व करती है। restrict सी स्तर पर), जिसमें प्रत्येक कॉल के लिए अलग-अलग मान हो सकते हैं।

हालांकि, इस मामले में, पहले फ़ंक्शन को लूप में इनलाइन किया जाता है, फिर इनलाइन कोड को डुप्लिकेट किया जाता है जब लूप को अनियंत्रित किया जाता है - और यह दोहराव आईडी नहीं बदलता है। इस की वजह से, LLVM में से कोई भी सोचता है कि a 'से किसी के साथ रों सकते उर्फ b , रों है, जो गलत है' क्योंकि a पहली और तीसरी कॉल उपनाम से दूसरी कॉल से b (सभी &mat[0] ओर इशारा करते हैं)।

आश्चर्यजनक रूप से, जीसीसी अलग-अलग आउटपुट के साथ इसे गलत तरीके से संकलित करता है। (क्लैंग और जीसीसी -ओ0 दोनों आउटपुट 7 10 ; क्लैंग एट -ओ3 आउटपुट 7 7 ; जीसीसी एट -ओ3 आउटपुट 10 7 ।) उह, मुझे वास्तव में उम्मीद है कि मैंने नहीं किया कुछ खराब करें और यूबी को आखिर जोड़ें, लेकिन मैं यह नहीं देखता कि कैसे ...

* यह उससे थोड़ा अधिक जटिल है, लेकिन इस मामले में, चूंकि copy किसी भी पॉइंटर अंकगणित का उपयोग नहीं करता है और दोनों पॉइंटर्स को लिखता है, असमानता a != b कॉल न करने के लिए आवश्यक और पर्याप्त है यूबी हो।

comex 13 अक्तू॰ 2018

👍59 ❤22 🎉8

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

मैं अभी भी अंतर्निहित मुद्दे का पता लगाने पर काम कर रहा हूं। दिलचस्प टिकट https://github.com/rust-lang/rust/issues/54462 है।

nagisa 7 अक्तू॰ 2018

👍2

@nagisa के न्यूनतम प्रजनन का उपयोग करना:

बिना किसी असुरक्षित कोड के न्यूनतम परीक्षण केस (1 कोडजेन यूनिट के साथ संकलन करना सुनिश्चित करें!):

fn linidx(row: usize, col: usize) -> usize {
    row * 1 + col * 3
}

fn swappy() -> [f32; 12] {
    let mut mat = [1.0f32, 5.0, 9.0, 2.0, 6.0, 10.0, 3.0, 7.0, 11.0, 4.0, 8.0, 12.0];

    for i in 0..2 {
        for j in i+1..3 {
            if mat[linidx(j, 3)] > mat[linidx(i, 3)] {
                    for k in 0..4 {
                            let (x, rest) = mat.split_at_mut(linidx(i, k) + 1);
                            let a = x.last_mut().unwrap();
                            let b = rest.get_mut(linidx(j, k) - linidx(i, k) - 1).unwrap();
                            ::std::mem::swap(a, b);
                    }
            }
        }
    }

    mat
}

fn main() {
    let mat = swappy();
    assert_eq!([9.0, 5.0, 1.0, 10.0, 6.0, 2.0, 11.0, 7.0, 3.0, 12.0, 8.0, 4.0], mat);
}

मैं त्रुटि पैदा करने वाले को खोजने के लिए LLVM के ऑप्टिमाइज़ेशन पास को द्विभाजित करने में सक्षम था।

इस कमांड को चलाने से कार्य निष्पादन योग्य होता है ( bug.rs को उस फ़ाइल के नाम से बदलें जिसमें आपने पुनरुत्पादन को सहेजा है)।

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2260 bug.rs

इस आदेश को चलाने के दौरान एक टूटा हुआ निष्पादन योग्य परिणाम होता है (`assert_eq`` विफल रहता है):

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2261 bug.rs

एलएलवीएम द्विभाजित आउटपुट

इस फ़ाइल के लिए, अनुकूलन 2261 Global Value Numbering on function (_ZN3bug6swappy17hdcc51d0e284ea38bE) अनुरूप है

Aaron1011 13 अक्तू॰ 2018

👍11 ❤7

एलएलवीएम संशोधनों को द्विभाजित करना (एलएलवीएमलैब द्विभाजित का उपयोग करके) इसे r305936-r305938, संभवतः r305938 तक सीमित कर देता है:

[BasicAA] फ़ॉलबैक के लिए आंशिक उपनाम के बजाय MayAlias का उपयोग करें।

ध्यान दें कि यह काफी पुराना बदलाव है, जून 2017 से।

संपादित करें: प्रतिबद्ध विवरण को देखते हुए, ऐसा लगता है कि बग उससे पहले मौजूद था, लेकिन बेसिकएए द्वारा मुखौटा किया गया था, बाद में उपनाम चलने से रोकता है, जो कि प्रतिबद्धता तय की गई है। मामले में getelementptr निर्देशों की एक जोड़ी के बीच एलियासिंग की जांच करना शामिल है जहां संकलक जानता है कि उनके पास एक ही आधार पता है लेकिन ऑफ़सेट नहीं जानता है।

संपादित 2: साथ ही, -enable-scoped-noalias=false को LLVM विकल्प के रूप में पास करना गलत संकलन को रोकता है। (यह आश्चर्य की बात नहीं है क्योंकि यह पूरी तरह से नोआलिया को संभालने में अक्षम करता है, लेकिन अगर यह मदद करता है ...)

comex 13 अक्तू॰ 2018

👍6 🎉2

प्री-जीवीएन आईआर पर एक नज़र से, मुझे लगता है कि यहां मूल कारण लूप अनोलिंग में हो सकता है, इस पर निर्भर करता है कि एलएलवीएम एलियासिंग एनोटेशन कैसे काम करता है, इसकी मेरी समझ सही है या नहीं।

जैसे कोड पर विचार करें

int *a, *b;
for (int i = 0; i < 4; i++) {
    a[i & 1] = b[i & 1];
}

जहां a[i & 1] और b[i & 1] एक ही पुनरावृत्ति के भीतर उपनाम नहीं हैं, लेकिन सामान्य रूप से a और b उपनाम हो सकते हैं।

एलएलवीएम आईआर में यह कुछ ऐसा होगा:

define void @test(i32* %addr1, i32* %addr2) {
start:
    br label %body

body:
    %i = phi i32 [ 0, %start ], [ %i2, %body ]
    %j = and i32 %i, 1
    %addr1i = getelementptr inbounds i32, i32* %addr1, i32 %j
    %addr2i = getelementptr inbounds i32, i32* %addr2, i32 %j

    %x = load i32, i32* %addr1i, !alias.scope !2
    store i32 %x, i32* %addr2i, !noalias !2

    %i2 = add i32 %i, 1
    %cmp = icmp slt i32 %i2, 4
    br i1 %cmp, label %body, label %end

end:
    ret void
}

!0 = !{!0}
!1 = !{!1, !0}
!2 = !{!1}

यदि हम इसे -loop-unroll माध्यम से चलाते हैं तो हमें मिलता है:

define void @test(i32* %addr1, i32* %addr2) {
start:
  br label %body

body:                                             ; preds = %start
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  %x.2 = load i32, i32* %addr1, !alias.scope !0
  store i32 %x.2, i32* %addr2, !noalias !0
  %addr1i.3 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.3 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.3 = load i32, i32* %addr1i.3, !alias.scope !0
  store i32 %x.3, i32* %addr2i.3, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

नोट करें कि लूप की सभी चार प्रतियां समान अलियासिंग डोमेन पर अलियासिंग मेटाडेटा का उपयोग कैसे करती हैं। एक पुनरावृत्ति के भीतर नोअलिया होने के बजाय, यह पूरे कार्य में नोअलिया है।

अंत में, -scoped-noalias -gvn हमें देता है:

define void @test(i32* %addr1, i32* %addr2) {
start:
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  store i32 %x, i32* %addr2, !noalias !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

और इसके परिणामस्वरूप गलत परिणाम होंगे यदि a = b + 1 ।

निम्नलिखित कोड के साथ सी से इस समस्या को पुन: उत्पन्न करना संभव है:

#include "stdio.h"

void copy(int * restrict to, int * restrict from) {
    *to = *from;
}

void test(int *a, int *b) {
    for (int i = 0; i < 4; i++) {
        copy(&b[i & 1], &a[i & 1]);
    }
}

int main() {
    int ary[] = {0, 1, 2};
    test(&ary[1], &ary[0]);
    printf("%d %d %d\n", ary[0], ary[1], ary[2]);
    return 1;
}

क्लैंग 6.0 के साथ यह 2 2 2 को -O0 और 1 2 2 को -O3 पर प्रिंट करता है। मुझे यकीन नहीं है कि यह कोड सी में restrict शब्दार्थ के तहत कानूनी है, लेकिन मुझे लगता है कि यह एलएलवीएम के सख्त noalias शब्दार्थ के तहत कानूनी होना चाहिए।

nikic 13 अक्तू॰ 2018

👍19 ❤4 🎉2

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

__attribute__((always_inline))
static inline void copy(int *restrict a, int *restrict b) {
    assert(a != b);
    *b = *a;
    *a = 7;
}

__attribute__((noinline))
void floppy(int mat[static 2], size_t idxs[static 3]) {
    for (int i = 0; i < 3; i++) {
        copy(&mat[i%2], &mat[idxs[i]]);
    }
}

int main() {
    int mat[3] = {10, 20};
    size_t idxs[3] = {1, 0, 1};
    floppy(mat, idxs);
    printf("%d %d\n", mat[0], mat[1]);
}

क्या हो रहा है:

copy() इनलाइन हो जाता है, जिसके परिणामस्वरूप कुछ ऐसा होता है:

for (int i = 0; i < 3; i++) {
    mat[idxs[i]] = mat[i%2]; mat[i%2] = 7;
}

LLVM लूप को अनियंत्रित करता है:

mat[idxs[0]] = mat[0]; mat[0] = 7; /* from copy(&mat[0%2], &mat[idxs[0]]) */
mat[idxs[1]] = mat[1]; mat[1] = 7; /* from copy(&mat[1%2], &mat[idxs[1]]) */
mat[idxs[2]] = mat[0]; mat[0] = 7; /* from copy(&mat[2%2], &mat[idxs[2]]) */

एलएलवीएम सोचता है कि mat[0] mat[idxs[1]] या mat[1] साथ उपनाम नहीं हो सकता है, एर्गो इसे mat[0] = 7; और mat[idxs[2]] = mat[0]; बीच बदला नहीं जा सकता है, यह सुरक्षित है बाद वाले को mat[idxs[2]] = 7; अनुकूलित करने के लिए वैश्विक मूल्य क्रमांकन।

  %8 = load i32, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13
  store i32 %8, i32* %7, align 4, !tbaa !8, !alias.scope !13, !noalias !10
  store i32 7, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13

comex 13 अक्तू॰ 2018

👍59 ❤22 🎉8

हे, ऐसा लगता है कि मैंने उसी स्पष्टीकरण को खोजने के लिए @nikic के साथ दौड़ लगाई। उनका टेस्ट केस थोड़ा अच्छा है :)

comex 13 अक्तू॰ 2018

🎉3

यह वास्तव में बहुत अच्छा समय है ^^ हम एक ही निष्कर्ष पर एक ही समय में लगभग एक ही कम परीक्षण मामले के साथ पहुंचे :)

इसे ठीक करने के लिए, शायद https://github.com/llvm-mirror/llvm/blob/54d4881c352796b18bfe7314662a294754e3a752/lib/Transforms/Utils/InlineFunction.cpp#L801 की तर्ज पर कुछ भी LoopUnrollPass में किया जाना चाहिए।

nikic 14 अक्तू॰ 2018

🎉2

मैंने इस समस्या के लिए https://bugs.llvm.org/show_bug.cgi?id=39282 पर LLVM बग रिपोर्ट सबमिट की है

nikic 14 अक्तू॰ 2018

🎉12 ❤5

और - केवल पूर्णता के लिए इसका उल्लेख करते हुए - मैंने जीसीसी को एक बग रिपोर्ट प्रस्तुत की क्योंकि इसने मेरे सी परीक्षण मामले को भी गलत तरीके से संकलित किया: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609

comex 14 अक्तू॰ 2018

❤8 🎉8

ट्राइएज: अगर मैं इसे सही ढंग से पढ़ रहा हूं, तो एलएलवीएम फिक्स स्वीकार कर लिया गया था (https://reviews.llvm.org/D9375)। मुझे यकीन नहीं है कि एलएलवीएम में वास्तव में विलय के लिए इसका क्या अर्थ है, या जब ऐसा हुआ; एलएलवीएम की संशोधन प्रक्रिया के बारे में अधिक जानकार किसी को यह जांचना चाहिए कि क्या समस्या अभी ठीक हो गई है (और किन संस्करणों के लिए)।

Phlosioneer 31 जुल॰ 2019

👍13

इसे मर्ज नहीं किया गया है, समीक्षा प्रक्रिया थोड़ी अजीब थी और जिस व्यक्ति ने इसे ठीक किया वह अब पैच की समीक्षा नहीं करता है।

mati865 31 जुल॰ 2019

👍4

https://reviews.llvm.org/D68484

cynecx 7 अक्तू॰ 2019

👍16

"पूर्ण प्रतिबंध" पैच सेट के साथ परीक्षण के लिए कॉल किया गया है। यह शायद मूल्यवान होगा यदि किसी ने llvm के शीर्ष पर रस्ट में noalias को फिर से सक्षम करने का प्रयास किया है जिसमें यह पैच सेट लागू है।

jrmuizel 30 अक्तू॰ 2019

👍11

मैं इसके लिए प्रयास करने को तैयार हूं।
मेरे पास मध्यम शक्तिशाली सर्वर (48 HT कोर, 128G RAM) तक पहुंच है और मुझे लगता है कि मैं पैच के साथ सब कुछ सही ढंग से बनाने का प्रबंधन कर सकता हूं।
एक बार जब मेरे पास एक काम करने वाला टूलचेन हो, तो आप किस क्रेट को आज़माने की सलाह देंगे?

PaulGrandperrin 30 अक्तू॰ 2019

👍6

मैंने llvm के अपस्ट्रीम मास्टर पर सभी रस्ट-विशिष्ट कमिट्स को मर्ज करना समाप्त कर दिया और फिर पैच लागू किया।
यहाँ परिणामी शाखा है: https://github.com/PaulGrandperrin/llvm-project/tree/llvm-master-with-rustlang-patches-and-D69542
अब मैं टूलचेन को संकलित करने की कोशिश करूँगा और इसे आज़माऊँगा

PaulGrandperrin 30 अक्तू॰ 2019

👍1

पहले सुनिश्चित करें कि आप वापस लौटते हैं: https://github.com/rust-lang/rust/pull/54639 ताकि जंग वास्तव में नोलियास उत्सर्जित कर रहा है।

कोशिश करने वाली पहली अच्छी चीज़ कुछ इस प्रकार है:

pub fn adds(a: &mut i32, b: &mut i32) {
    *a += *b;
    *a += *b;
}

और पुष्टि करें कि यह कुछ इस तरह संकलित करता है:

example::adds:
        mov     eax, dword ptr [rsi]
        add     eax, eax
        add     dword ptr [rdi], eax
        ret

और नहीं

example::adds:
        mov     eax, dword ptr [rdi]
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        ret

इसके बाद, सुनिश्चित करें कि https://github.com/rust-lang/rust/issues/54462#issue -362850708 का कोड अब गलत नहीं है।

jrmuizel 30 अक्तू॰ 2019

@jrmuizel ध्यान दें कि # 54639 करता @nagisa शामिल की न्यूनतम प्रतिलिपि प्रस्तुत एक नया संकलक परीक्षण के रूप में # 54,462 के लिए। शायद एक पूर्ण वापसी क्रम में नहीं है?

HadrienG2 30 अक्तू॰ 2019

मुझे नहीं लगता कि इसे शामिल करना महत्वपूर्ण है या नहीं क्योंकि AFAIK यह केवल कुछ डिफ़ॉल्ट ध्वज को बदलने के बारे में है (जिसे -Zmutable-noalias=yes ओवरराइड किया जा सकता है) और मैं मैन्युअल रूप से उल्लिखित परीक्षण फ़ाइल को संकलित कर सकता हूं।

जैसा कि आप जानते हैं, मैं अभी भी एलएलवीएम बनाने की कोशिश कर रहा हूं, लेकिन अभी तक मुझे जंग विशिष्ट पैच के साथ या उसके बिना एक संकलन त्रुटि मिलती है (यानी: बस अपस्ट्रीम का एलएलवीएम मास्टर + पैच भी विफल हो जाता है):

In file included from /usr/include/c++/8/cmath:45,
                 from /opt/rust/src/llvm-project/llvm/include/llvm-c/DataTypes.h:28,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Support/DataTypes.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/Hashing.h:47,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:12,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:16,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp: In function ‘void llvm::cloneNoAliasScopes(llvm::ArrayRef<llvm::MetadataAsValue*>, llvm::DenseMap<llvm::MDN
ode*, llvm::MDNode*>&, llvm::DenseMap<llvm::MetadataAsValue*, llvm::MetadataAsValue*>&, llvm::StringRef, llvm::LLVMContext&)’:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:174:30: error: no matching function for call to ‘llvm::AliasScopeNode::AliasScopeNode(double)’
         llvm::AliasScopeNode SNAN(MD);
                              ^~~~
In file included from /opt/rust/src/llvm-project/llvm/include/llvm/IR/TrackingMDRef.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/DebugLoc.h:17,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instruction.h:21,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/BasicBlock.h:22,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instructions.h:27,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:22,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note: candidate: ‘llvm::AliasScopeNode::AliasScopeNode(const llvm::MDNode*)’
   explicit AliasScopeNode(const MDNode *N) : Node(N) {}
            ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::MDNode*’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode()’
   AliasScopeNode() = default;
   ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note:   candidate expects 0 arguments, 1 provided
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(const llvm::AliasScopeNode&)’
 class AliasScopeNode {
       ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::AliasScopeNode&’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(llvm::AliasScopeNode&&)’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘llvm::AliasScopeNode&&’
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:177:31: error: request for member ‘getName’ in ‘__builtin_nans(((const char*)""))’, which is of non-class ty
pe ‘double’
         auto ScopeName = SNAN.getName();
                               ^~~~~~~
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:187:39: error: request for member ‘getDomain’ in ‘__builtin_nans(((const char*)""))’, which is of non-class
type ‘double’
             const_cast<MDNode *>(SNAN.getDomain()), Name);
                                       ^~~~~~~~~
[ 75%] Building CXX object lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/RDFCopy.cpp.o
make[2]: *** [lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/build.make:635: lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/NoAliasUtils.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

PaulGrandperrin 30 अक्तू॰ 2019

हो सकता है कि एलएलवीएम मास्टर पहले से ही पैच के साथ सिंक से बाहर हो गया हो (जो यह देखते हुए हो सकता है कि पैच कितना बड़ा है और एलएलवीएम मास्टर कितनी तेजी से आगे बढ़ रहा है) और आपको एलएलवीएम मास्टर के पुराने संशोधन के खिलाफ निर्माण करने की आवश्यकता है? इस बारे में पैच लेखक को पिंग करना निश्चित रूप से सार्थक होगा।

HadrienG2 30 अक्तू॰ 2019

पैच के साथ बनने वाले पुराने संशोधन को खोजने की कोशिश कर रहा हूं, ठीक यही मैं कर रहा हूं :-)

PaulGrandperrin 30 अक्तू॰ 2019

मुझे अब यकीन है कि समस्या llvm/मास्टर के साथ नहीं है बल्कि पैच से है।
llvm/master की सबसे पुरानी कमिटमेंट जो अभी भी पैच के साथ संगत है, वह है https://github.com/llvm/llvm-project/commit/5b99c189b3bfc0faa157f7ca39652c0bb8c315a7 लेकिन इससे भी पहले पैच कंपाइल करने में विफल रहता है।
मैं अब सी ++ को समझने की कोशिश करने के लिए बहुत थका हुआ और आलसी हूं, मैं कल फिर कोशिश करूंगा।
इस बीच, क्या कोई मदद मांगने के लिए पैच के लेखक से संपर्क कर सकता है?

PaulGrandperrin 30 अक्तू॰ 2019

❤1

मुझे नहीं लगता कि आप rustllvm को पैच किए बिना रस्ट (वास्तव में इसे बनाने के बाद) के साथ मास्टर एलएलवीएम का आसानी से उपयोग कर

mati865 31 अक्तू॰ 2019

@ mati865 मैंने पहले जंग के llvm-9 कांटे पर पैच लगाने की कोशिश की, लेकिन यह बहुत मामूली भी नहीं था ...

PaulGrandperrin 31 अक्तू॰ 2019

पैच स्पष्ट रूप से llvm/ llvm-project@82d3ba87d06f9e2abc6e27d8799587d433c56630 के शीर्ष पर

jrmuizel 31 अक्तू॰ 2019

@jrmuizel धन्यवाद मैं कोशिश करूँगा!
इस बीच, मैं llvm मास्टर के साथ निर्माण करने के लिए rustllvm को सफलतापूर्वक अनुकूलित करने में सक्षम हूं।

PaulGrandperrin 31 अक्तू॰ 2019

👍2 😕1

पिंग @PaulGrandperrin , कोई अपडेट?

martingronlund 7 जन॰ 2020

👍5

https://reviews.llvm.org/D68484

वास्तव में, अनुमानित समयरेखा क्या है और इसके आकार को देखते हुए इस पैच के कभी भी विलय होने की कुल संभावना क्या है?

MSxDOS 28 फ़र॰ 2020

👍2

@MSxDOS आप

bstrie 28 फ़र॰ 2020

यहाँ नवीनतम स्थिति है जो मैंने देखी है: https://reviews.llvm.org/D69542#1836439

jrmuizel 28 फ़र॰ 2020

👍8

मुझे लगता है कि किसी बिंदु पर यह प्रासंगिक नहीं रहेगा यदि ~~https://github.com/bytecodealliance/cranelift~~ https://github.com/bjorn3/rustc_codegen_cranelift काम करता है?~~

leeoniya 28 फ़र॰ 2020

@leeoniya , ऑप्ट बिल्ड के लिए क्रेनलिफ्ट का उपयोग करने की कोई अल्पकालिक योजना नहीं है। क्रेनलिफ्ट में अनुकूलन कार्य का एक गुच्छा नहीं है जो इसे संभव बनाने के लिए आवश्यक होगा।

jrmuizel 28 फ़र॰ 2020

👍12

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

fn baz(s: &mut S) {
    if s.y < 10 {
        s.x = foo();
    }

    if s.y < 5 {
        s.x = foo();
    }
}

चूंकि यह &mut माध्यम से संरचना सदस्यों तक पहुंचता है, यह मानता है कि s.x और s.y उपनाम कर सकते हैं, इसलिए s.y लिए एक के बजाय दो मेमोरी एक्सेस की आवश्यकता होती है। यह वास्तव में दुर्भाग्यपूर्ण है, जब आप विचार करते हैं कि सदस्य कितनी बार पढ़ता/लिखता है &mut माध्यम से एक विशिष्ट कार्यक्रम में इंटरलीव किया जाना चाहिए।

संपादित करें: कुछ परीक्षणों के आधार पर, ऐसा लगता है कि यह ऐसे सभी पढ़ने/लिखने को प्रभावित नहीं करता है, जो आश्चर्य की बात नहीं है, क्योंकि अगर ऐसा होता है तो शायद यह प्रदर्शन को मार देगा। फिर भी, -Z mutable-noalias उपयोग उपरोक्त उदाहरण में डबल मेमोरी एक्सेस को ठीक करता है, इसलिए कुछ मामलों का भंडाफोड़ हो सकता है।

tgnottingham 13 सित॰ 2020

@PaulGrandperrin इस पैच अप का एक नया संस्करण https://reviews.llvm.org/D69542 llvm@9fb46a452d4e5666828c95610ceac8dcd9e4ce16 पर आधारित है

jrmuizel 14 सित॰ 2020

👍17 ❤10

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

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

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

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