gc कंपाइलर स्टेटिक सिंगल असाइनमेंट (एसएसए) अनुकूलन नियमों का वर्णन करने के लिए एक विशेष लिस्प जैसी ऑब्जेक्ट-ओरिएंटेड भाषा ( डीएसएल ) का उपयोग करता है।

मैं इस भाषा के मुख्य तत्वों, इसकी विशेषताओं और सीमाओं का विश्लेषण करने का प्रस्ताव करता हूं।
एक अभ्यास के रूप में, आइए गो कंपाइलर को एक निर्देश की पीढ़ी में जोड़ें, जो पहले उत्पन्न नहीं हुआ था, जो अभिव्यक्ति को a*b+c अनुकूलित करता है।

यह गो एसएसए संकलक बैकएंड के आंतरिक के बारे में एक श्रृंखला का पहला लेख है, इसलिए, नियमों के डीएसएल विवरण की समीक्षा करने के अलावा, हम अपने अगले सत्र के लिए आवश्यक आधार बनाने के लिए संबंधित घटकों पर विचार करेंगे।

परिचय

ऐन्टेनेटेड एएसटी से एसएसए दृश्य उत्पन्न करने के समय फ्रंटएंड गो कंपाइलर समाप्त होता है। रूपांतरण के लिए जिम्मेदार कार्य cmd / संकलन / आंतरिक / gc / ssa.go. में पाए जा सकते हैं। एसएसए बैकएंड का प्रवेश बिंदु ssa.Compile फ़ंक्शन है, जिसे cmd / compile / आंतरिक / ssa / compile.go में परिभाषित किया गया है।

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

एस-एक्सप्रेशन का उपयोग करके परिवर्तन नियमों का वर्णन किया गया है। इन भावों के तत्व ssa.Value हैं । सबसे सरल मामले में, ये नियम आपको एक ssa.Value को दूसरे के साथ बदलने की अनुमति देते हैं।

उदाहरण के लिए, नीचे दिया गया कोड 8-बिट स्थिरांक के गुणन को ढहता है:

 (Mul8 (Const8 [c]) (Const8 [d])) -> (Const8 [int64(int8(c*d))]) 

SSA मानों की दो मुख्य श्रेणियां हैं: उच्च-स्तर, लक्ष्य मशीन से लगभग स्वतंत्र, और जो कि आर्किटेक्चर-विशिष्ट हैं (आमतौर पर 1-in-1 मशीन निर्देशों के लिए मैप की जाती हैं)।

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

नियमों से जुड़े सभी कोड cmd / संकलन / आंतरिक / ssa / gen में निहित हैं। हम दो सेटों पर विचार करेंगे:

1. genericOps.go - मशीन-स्वतंत्र संचालन।
2. AMD64Ops.go - संचालन GOARCH=AMD64 (64-बिट x86) के लिए विशिष्ट है।

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

ऑप्टिमाइज़र के बाद, एक कोड जनरेटर खेलने में आता है। AMD64 के लिए, कोड जनरेशन कार्यान्वयन पैकेज cmd / संकलन / आंतरिक / amd64 में पाया जा सकता है। कोड जनरेटर का कार्य ssa.Block और ssa.Value को अनुक्रम obj से बदलना है। असेंबलर मशीन कोड एकत्र करेगा, जो लिंक करने के बाद निष्पादन के लिए तैयार होगा।

अनुकूलन नियम

यदि ऑपरेशन परिभाषा वाली फ़ाइलों को " ${ARCH}Ops.go " नाम दिया गया है, तो अनुकूलन नियमों को " ${ARCH}.Rules " में रखा गया है।

उच्च-स्तरीय नियम सरल रूपांतरण करते हैं, अधिकांश निरंतर अभिव्यक्तियों की तह , साथ ही साथ कुछ परिवर्तन जो बाद के प्रसंस्करण को सरल बनाते हैं।

निम्न-स्तरीय नियमों वाली प्रत्येक फ़ाइल में दो भाग होते हैं:

1. कम करना - मशीन समकक्षों के साथ अमूर्त संचालन की जगह।
2. अनुकूलन स्वयं।

एक मशीन में एक ऑपरेशन को कम करने का एक उदाहरण:

 (Const32 [val]) -> (MOVLconst [val]) // L - long, 32- (Const64 [val]) -> (MOVQconst [val]) // Q - quad, 64- | | generic op | AMD64 op 

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

ऑपरेशन्स में एक एमनोमोनिक नाम है, जिसे आमतौर पर एक ओपकोड कहा जाता है। वास्तुकला-निर्भर संचालन के ऑपकोड आमतौर पर वास्तविक निर्देशों के नामों को दर्शाते हैं।

नियम विवरण भाषा सिंटेक्स

मूल व्याकरण नियम में वर्णित है।

 // rule syntax: // sexpr [&& extra conditions] -> [@block] sexpr // // sexpr are s-expressions (lisp-like parenthesized groupings) // sexpr ::= [variable:](opcode sexpr*) // | variable // | <type> // | [auxint] // | {aux} // // aux ::= variable | {code} // type ::= variable | {code} // variable ::= some token // opcode ::= one of the opcodes from the *Ops.go files 

 //  : // sexpr [&&  ] -> [@block] sexpr // // sexpr -  S- (   ) // sexpr ::= [variable:](opcode sexpr*) // | variable // | <type> // | [auxint] // | {aux} // // aux ::= variable | {code} // type ::= variable | {code} // variable ::= Go  ( ) // opcode ::=   *Ops.go  

यह भी ध्यान देने योग्य है कि " // " टिप्पणियों की अनुमति है अंदर .Rules फ़ाइलें।

आइए एक सरल उदाहरण देखें जिसमें ये सभी तत्व शामिल हैं:

  Opcode=ADDLconst -    32-  : AuxInt=c - ,    `x` : : (ADDLconst [c] x) && int32(c)==0 -> x | / | / | | / | / | | / | /    | /   ( `&&`    ) ,     

ये सभी व्याख्यात्मक हस्ताक्षर वैध नियम रिकॉर्ड का हिस्सा नहीं हैं।

यह नियम x+0 को x परिवर्तित करता है। शर्तों अनुभाग के अंदर सब कुछ एक सामान्य गो कोड है,
जब तक भावों तक सीमित नहीं, जिसका परिणाम एक bool होना चाहिए।
आप rewrite.go में परिभाषित विधेय कह सकते हैं।

सामान्य ऑपकोड के अलावा, संयोजन का उपयोग किया जा सकता है जो कई नियमों को जन्म देता है:

 (ADD(Q|L)const [off] x:(SP)) -> (LEA(Q|L) [off] x) //  Q|L alternation: (ADDQconst [off] x:(SP)) -> (LEAQ [off] x) (ADDLconst [off] x:(SP)) -> (LEAL [off] x) //    `x`: (ADDQconst [off] (SP)) -> (LEAQ [off] (SP)) (ADDLconst [off] (SP)) -> (LEAL [off] (SP)) 

(SP) जेनेरिकऑप्स.ओगो में से एक ऑपरेशन है और हार्डवेयर स्टैक के लिए पॉइंटर लोड करने को व्यक्त करता है। आर्किटेक्चर के लिए जहां कोई हार्डवेयर SP , इसका अनुकरण किया जाता है।

टेम्प्लेट में वैरिएबल की विशेषताएं (S- एक्सप्रेशन के बाईं ओर -> ):

• चर, जैसे x , के माध्यम से अभिव्यक्ति के बिना : कुछ भी कैप्चर करें
• एक नियमित चर की तरह, _ किसी भी मूल्य को पकड़ता है, लेकिन परिणाम को अनदेखा किया जा सकता है

 //       :    ADDQconst, //          : (ADDQconst _) -> v (ADDQconst x) -> (ADDQconst x) 

यदि AuxInt निर्दिष्ट नहीं है (वर्ग कोष्ठकों में अभिव्यक्ति), तो नियम किसी भी AuxInt मान पर फायर करेगा। इसी तरह से {} -पैरामीटर (नीचे उनके बारे में)।

नाम v अर्थ है सबसे बाहरी कैप्चर किया गया रूप।
उदाहरण के लिए, अभिव्यक्ति (ADDQconst (SUBQconst x)) बाहरी रूप ADDQconst ।

चर का उपयोग कई बार किया जा सकता है, इससे आपको एस-एक्सप्रेशन के कई हिस्सों को एक दूसरे से मेल खाने की आवश्यकता होती है:

 (ADDQconst [v] (ADDQconst [v] x)) // , ,  "x+2+2" (x+v+v). 

नियमों में प्रकार

कुछ मामलों में, स्पष्ट रूप से उत्पन्न और / या मिलान के प्रकार को इंगित करना आवश्यक है।
प्रकार को "त्रिकोणीय कोष्ठक" में दर्शाया गया है, C ++ टेम्पलेट्स में एक प्रकार के तर्क के रूप में:

 // typ.UInt32 -   BTSLconst. // BSFL    typ.UInt32,    //    . (Ctz16 x) -> (BSFL (BTSLconst <typ.UInt32> [16] x)) 

प्रकारों के अलावा, "वर्ण" हैं (या, अधिक सार्वभौमिक रूप से - Aux गुण)।

 (StaticCall [argsWidth] {target} mem) -> (CALLstatic [argsWidth] {target} mem) 

• [argsWidth] - Value.AuxInt StaticCall - तर्कों का कुल आकार पारित हुआ
• {target} - Value.Aux । StaticCall - फ़ंक्शन कहा जाता है
• <typ.UInt32> - Value.Type । मान प्रकार

Aux और AuxInt शब्दार्थ ऑपरेशन से ऑपरेशन तक बहुत भिन्न होते हैं। इस मामले में प्रलेखन का सबसे अच्छा स्रोत *Ops.go फाइलें हैं। प्रत्येक opData opcode opData में एक aux क्षेत्र होता है जो इन क्षेत्रों की व्याख्या करने का तरीका बताता है।

प्रकार के विवरण के लिए पैकेज cmd / संकलन / आंतरिक / प्रकार का उपयोग किया जाता है । कुछ प्रकार एसएसए बैकएंड के लिए types.TypeFlags , उदाहरण के लिए types.TypeFlags , बाकी cmd/compile/internal/gc और types.TypeFlags cmd/compile/internal/gc types.TypeFlags बीच आम हैं।

विशेष प्रकार के

एक विशेष प्रकार के प्रकार है। types.TypeMem , जो एक ही बार में कई कार्य करता है:

1. आपको मेमोरी एक्सेस पैटर्न द्वारा ssa.Value को सॉर्ट और समूह करने की अनुमति देता है। विशेष रूप से, यह बेस ब्लॉक (उनके बारे में नीचे) के ढांचे के भीतर सही निष्पादन आदेश की गारंटी देता है।
2. कार्यक्रम में मेमोरी स्ट्रीम की स्थिति निर्धारित करता है। यदि निर्देश मेमोरी को संशोधित करता है, तो इस प्रकार का एक नया SSA मान टाइप किया जाता है। इस ऑपरेशन के परिणामस्वरूप टाइप types.TypeMem जाएगा।

OpPhi के विशेष अर्थ की OpPhi , मेमोरी को ऑप्टिमाइज़र के कई चरणों में असाधारण रूप से व्याख्या की जाती है।

एक अन्य विशेष प्रकार types.TypeFlags ऊपर उल्लेख किया है। यह प्रकार सीपीयू झंडे पैदा करने वाले अनुदेश का वर्णन करता है।

इस मामले में, ADDQ जैसे निर्देश, हालांकि वे झंडे उत्पन्न करते हैं, वे प्रकार के नहीं होते हैं। types.Flags , लेकिन clobberFlags विशेषता के साथ चिह्नित होते हैं।

types.Flags उपयोग CMPQ जैसे निर्देशों के परिणाम को उजागर करने के लिए किया जाता है, जो उनके किसी भी स्पष्ट ऑपरेंड के परिणाम को नहीं लिखते हैं, लेकिन केवल प्रोसेसर की आंतरिक स्थिति को अपडेट करते हैं, जिसका उपयोग अगले निर्देश द्वारा किया जा सकता है।

SETL जैसे निर्देश आपको झंडे को "पढ़ने" और ssa.Value रूप में वापस करने की अनुमति देते हैं, जिसे एक रजिस्टर में रखा जा सकता है।

  L-less than G-greater than | | (SETL (InvertFlags x)) -> (SETG x) | ,   

SSA निरीक्षण कार्यक्रम

मान लीजिए कि हमारे पास इस तरह का एक कार्यक्रम है ( example.go ):

 package example func fusedMulAdd(a, b, c float64) float64 { return a*c + b } 

हम SSA कोड को देख सकते हैं जो fusedMulAdd फ़ंक्शन के लिए fusedMulAdd है:

 $ GOSSAFUNC=fusedMulAdd go tool compile example.go > ssa.txt 

अब कार्यशील (वर्तमान) निर्देशिका की जाँच करें:

• ssa.txt में टेक्ट डंप शामिल है।
• ssa.html , जो स्वचालित रूप से उत्पन्न होता है, उसमें समान जानकारी होती है, लेकिन अधिक संवादात्मक और आसानी से पढ़ने योग्य प्रारूप में। ब्राउज़र में खोलने का प्रयास करें।

 v7 (4) MOVSD a(SP), X0 v11 (4) MOVSD c+16(SP), X1 v12 (4) MULSD X1, X0 v6 (4) MOVSD b+8(SP), X1 v13 (4) ADDSD X1, X0 v15 (4) MOVSD X0, ret+24(SP) b1 (4) RET 

lower चरण के बाद fusedMulAdd लिए यह SSA प्रोग्राम fusedMulAdd दिखता है: (ssa.html):

 lower [77667 ns] b1: v1 (?) = InitMem <mem> v2 (?) = SP <uintptr> v7 (?) = LEAQ <*float64> {~r3} v2 v8 (3) = Arg <float64> {a} v9 (3) = Arg <float64> {b} v10 (3) = Arg <float64> {c} v12 (+4) = MULSD <float64> v8 v10 v13 (4) = ADDSD <float64> v12 v9 v14 (4) = VarDef <mem> {~r3} v1 v15 (4) = MOVSDstore <mem> {~r3} v2 v13 v14 Ret v15 (line +4) 

इसका अनुवाद एस-एक्सप्रेशन में किया जा रहा है:

 (MOVQstore {~r3} (SP) (ADDSD (MULSD (Arg {a}) (Arg {c})) (Arg {b}))) 

 regalloc [87237 ns] b1: v1 (?) = InitMem <mem> v14 (4) = VarDef <mem> {~r3} v1 v2 (?) = SP <uintptr> : SP v8 (3) = Arg <float64> {a} : a[float64] v9 (3) = Arg <float64> {b} : b[float64] v10 (3) = Arg <float64> {c} : c[float64] v7 (4) = LoadReg <float64> v8 : X0 v11 (4) = LoadReg <float64> v10 : X1 v12 (+4) = MULSD <float64> v7 v11 : X0 v6 (4) = LoadReg <float64> v9 : X1 v13 (4) = ADDSD <float64> v12 v6 : X0 v15 (4) = MOVSDstore <mem> {~r3} v2 v13 v14 Ret v15 (line +4) 

नए अनुकूलन नियम जोड़ना

FMA वाले प्रोसेसर पर , हम दो के बजाय एक निर्देश में a*c + b गणना कर सकते हैं।

इलिया तोकर के लेखन के आधार के रूप में CL117295 लें।

आपकी सुविधा के लिए, मैंने एक diff पैच तैयार किया है।

1. एक नया ऑपरेशन जोड़ना - FMASD

फ़ाइल compile/internal/ssa/gen/AMD64Ops.go में AMD64ops स्लाइस AMD64ops और एक नया तत्व (कहीं भी) जोड़ें:

 { // fp64 fma name: "FMASD", //   SSA argLength: 3, reg: fp31, //   regalloc,   resultInArg0: true, //     source,  destination asm: "VFMADD231SD", //   }, 

चूंकि पहले कोई ऑपरेशन (fp,fp,fp -> fp) थे, इसलिए आपको एक नए क्वालीफायर को परिभाषित करने की आवश्यकता है:

  fp01 = regInfo{inputs: nil, outputs: fponly} fp21 = regInfo{inputs: []regMask{fp, fp}, outputs: fponly} + fp31 = regInfo{inputs: []regMask{fp, fp, fp}, outputs: fponly} 

2. एक अनुकूलन नियम जोड़ना

 (ADDSD (MULSD xy) z) -> (FMASD zxy) 

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

संकलक ऐसे चेक के लिए config का उपयोग करता है:

 //  config.useFMA=false,    . (ADDSD (MULSD xy) z) && config.useFMA-> (FMASD zxy) 

 $ lscpu | grep fma 

3. कोड पीढ़ी का कार्यान्वयन

अब, ssaGenValue फ़ंक्शन में, compile/internal/amd64/ssa.go में परिभाषित किया गया है, आपको FMASD लिए कोड पीढ़ी जोड़ने की आवश्यकता है:

 func ssaGenValue(s *gc.SSAGenState, v *ssa.Value) { switch v.Op { case ssa.OpAMD64FMASD: p := s.Prog(v.Op.Asm()) //   obj.Prog    // From:  source . p.From = obj.Addr{Type: obj.TYPE_REG, Reg: v.Args[2].Reg()} // To: destination . // v.Reg()  ,      FMASD. p.To = obj.Addr{Type: obj.TYPE_REG, Reg: v.Reg()} // From3:  source . //  From3 .     //  RestArgs,    source ,  . p.SetFrom3(obj.Addr{ Type: obj.TYPE_REG, Reg: v.Args[1].Reg(), }) if v.Reg() != v.Args[0].Reg() { //   resultInArg0 s := v.LongString() v.Fatalf("input[0] and output not in same register %s", s) } //    ,     case. } } 

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

जाँच परिणाम

पहला कदम अद्यतन gen/AMD64Ops.go और gen/AMD64.Rules से गो कोड उत्पन्न gen/AMD64.Rules ।

 #  GOROOT  ,   ,   `go env GOROOT`. cd $GOROOT/src/cmd/compile/internal/ssa/gen && go run *.go 

अगला, हमें अपना नया संकलक बनाने की आवश्यकता है:

 go install cmd/compile 

अब, एक ही उदाहरण को संकलित करते समय, हमें एक अलग मशीन कोड मिलता है:

 - v7 (4) MOVSD a(SP), X0 - v11 (4) MOVSD c+16(SP), X1 - v12 (4) MULSD X1, X0 - v6 (4) MOVSD b+8(SP), X1 - v13 (4) ADDSD X1, X0 - v15 (4) MOVSD X0, ret+24(SP) - b1 (4) RET + v12 (4) MOVSD b+8(SP), X0 + v7 (4) MOVSD a(SP), X1 + v11 (4) MOVSD c+16(SP), X2 + v13 (4) VFMADD231SD X2, X1, X0 + v15 (4) MOVSD X0, ret+24(SP) + b1 (4) RET 

बुनियादी ब्लॉक

अब जब सबसे कठिन काम हो गया है, तो आइए आधार ब्लॉकों के बारे में बात करते हैं।

जिन मूल्यों को हमने ऊपर अनुकूलित किया है वे ब्लॉक में हैं, और ब्लॉक फ़ंक्शन में हैं।

ब्लॉक, जैसे ssa.Value , सार और मशीन-निर्भर हैं। सभी ब्लॉकों में ठीक एक प्रविष्टि बिंदु है और 0 से 2 गंतव्य ब्लॉकों (ब्लॉक के प्रकार के आधार पर) है।

सबसे सरल ब्लॉक हैं If , Exit और Plain :

• Exit ब्लॉक में 0 असाइनमेंट ब्लॉक हैं। ये पत्ती ब्लॉक हैं जो गैर-स्थानीय कूद बनाते हैं, उदाहरण के लिए, panic का उपयोग करते हुए।
• Plain ब्लॉक में 1 असाइनमेंट ब्लॉक होता है। ब्लॉक के सभी निर्देशों को दूसरे ब्लॉक में पूरा करने के बाद इसे बिना शर्त कूद माना जा सकता है।
• If ब्लॉक में 2 गंतव्य ब्लॉक हैं। संक्रमण की स्थिति ( Block.Control ) के आधार पर किया जाता है।

यहाँ AMD64 ब्लॉक में सार ब्लॉक को फिर से लिखने के सरल उदाहरण हैं:

   "then" ( ) |  "else" ( ) | | (If (SETL cmp) yes no) -> (LT cmp yes no) (If (SETLE cmp) yes no) -> (LE cmp yes no) 

कंपाइलर के एसएसए भाग में अन्य अनुकूलन चरणों के संदर्भ में ब्लॉकों के विषय पर अधिक विस्तार से विचार किया जाएगा।

अनुकूलन नियमों की सीमाएं

एसएसए बैकेंड के अपने फायदे हैं। कुछ अनुकूलन O(1) में संभव हैं। हालांकि, इसमें कमियां भी हैं, जिसके कारण अकेले अनुकूलक का SSA पर्याप्त नहीं होगा, कम से कम तब तक जब तक इसके कार्यान्वयन के कुछ पहलू नहीं बदल जाते।

मान लें कि आप append करना चाहते हैं:

 xs = append(xs, 'a') xs = append(xs, 'b') // => xs = append(xs, 'a', 'b') 

जिस समय एसएसए उत्पन्न होता है, उस समय कोड की उच्च-स्तरीय संरचना खो जाती है और append , एक सामान्य कार्य नहीं होने के कारण, पहले से ही युक्त ब्लॉक के शरीर में निर्मित होता है। आपको एक बोझिल नियम लिखना होगा जो append लिए सृजित परिचालनों के संपूर्ण अनुक्रम को पकड़ता है।

विशेष रूप से .Rules बारे में बोलते हुए, फिर इस DSL में ब्लॉक ( ssa.Block ) के साथ कमजोर काम है। इस भाषा में अभिव्यक्ति के लिए ब्लॉकों से जुड़ा कोई भी निरंकुश अनुकूलन असंभव है। आंशिक ब्लॉक अद्यतन संभव नहीं है। ब्लॉक को बाहर करना भी असंभव है (लेकिन First ब्लॉक के रूप में एक हैक है, जिसका उपयोग डेड कोड को हटाने के लिए किया जाता है)।

भले ही कुछ कमियां ठीक करने योग्य हों, अधिकांश कंपाइलर इस बात से सहमत हैं कि कोड का प्रतिनिधित्व करने के लिए कोई एकल और बेहतर मध्यवर्ती रूप नहीं है।

जाओ कि तेजी से चला जाता है

यदि आप कुछ शांत अनुकूलन नियमों के साथ आते हैं, तो बेझिझक इसे go-review.googlesource.com पर भेजें। मुझे समीक्षा करने में खुशी होगी (CC में iskander.sharipov@intel.com में जोड़ें)।

हैप्पी हैकिंग कंपाइलर!

बोनस सामग्री

जाने या बदले गए SSA नियमों में अच्छे पैच के उदाहरण:

• CL99656: cmd / संकलित / आंतरिक / ssa: IMUL3 {L / Q} के लिए MUL {L / Q} x x पर कास्ट
• CL102277: cmd / संकलन / आंतरिक / ssa: दूर amd64 पर डबल NEG का अनुकूलन करें
• CL54410: cmd / संकलन / आंतरिक / ssa: amse64 पर शून्य से sse का उपयोग करें
• CL58090: cmd / संकलन / आंतरिक / ssa: amd64 पर निरर्थक ज़ीरोक्स्टेंशन हटा दें
• CL95475: cmd / संकलन / आंतरिक / ssa: amd64 पर बाइट स्टोर को मिलाएं
• CL97175: cmd / संकलन / आंतरिक / ssa: arm64 पर लगातार LittleEndian स्टोर्स को मिलाएं
• CL115617: cmd / संकलन / आंतरिक / ssa: बेकार शून्य एक्सटेंशन को हटा दें
• CL101275: cmd / संकलन: amd64 LEAL {1,2,4,8} ops जोड़ें

इतनी देर पहले नहीं, एक README दस्तावेज़ संकलक के एसएसए भाग का वर्णन करने के लिए दिखाई दिया।
पढ़ने की सलाह दी।