LLVM Go-ს პერსპექტივიდან

შემდგენელის შემუშავება ძალიან რთული ამოცანაა. მაგრამ, საბედნიეროდ, LLVM-ის მსგავსი პროექტების განვითარებით, ამ პრობლემის გადაწყვეტა მნიშვნელოვნად გამარტივებულია, რაც საშუალებას აძლევს ერთ პროგრამისტსაც კი შექმნას ახალი ენა, რომელიც შესრულებით ახლოსაა C-სთან. LLVM-თან მუშაობა გართულებულია იმით, რომ ეს სისტემა წარმოდგენილია დიდი რაოდენობით კოდით, რომელიც აღჭურვილია მცირე დოკუმენტაციით. ამ ხარვეზის გამოსწორების მიზნით, მასალის ავტორი, რომლის თარგმანსაც დღეს ვაქვეყნებთ, აპირებს აჩვენოს Go-ში დაწერილი კოდების მაგალითები და აჩვენოს, თუ როგორ ითარგმნება ისინი პირველად წადი SSAდა შემდეგ LLVM IR-ში შემდგენელის გამოყენებით თინიგო. Go SSA და LLVM IR კოდი ოდნავ რედაქტირებულია, რათა წაშალოს ის, რაც არ არის შესაბამისი აქ მოცემულ ახსნა-განმარტებებთან, რათა ახსნა უფრო გასაგები გახდეს.

პირველი მაგალითი

პირველი ფუნქცია, რომელსაც აქ ვაპირებ, არის რიცხვების დამატების მარტივი მექანიზმი:

func myAdd(a, b int) int{
    return a + b
}

ეს ფუნქცია ძალიან მარტივია და, ალბათ, არაფერი შეიძლება იყოს უფრო მარტივი. ის ითარგმნება შემდეგ Go SSA კოდში:

func myAdd(a int, b int) int:
entry:
    t0 = a + b                                                    int
    return t0

ამ ხედვით, მონაცემთა ტიპის მინიშნებები მოთავსებულია მარჯვნივ და უმეტეს შემთხვევაში მათი იგნორირება შესაძლებელია.

ეს პატარა მაგალითი უკვე გაძლევთ საშუალებას დაინახოთ SSA-ს ერთი ასპექტის არსი. კერძოდ, კოდის SSA ფორმაში გადაყვანისას, თითოეული გამოხატულება იშლება ყველაზე ელემენტარულ ნაწილებად, საიდანაც იგი შედგება. ჩვენს შემთხვევაში, ბრძანება return a + b, ფაქტობრივად, წარმოადგენს ორ ოპერაციას: ორი რიცხვის დამატება და შედეგის დაბრუნება.

გარდა ამისა, აქ შეგიძლიათ ნახოთ პროგრამის ძირითადი ბლოკები; ამ კოდში არის მხოლოდ ერთი ბლოკი - შესვლის ბლოკი. ბლოკებზე დაწვრილებით ქვემოთ ვისაუბრებთ.

Go SSA კოდი ადვილად გარდაიქმნება LLVM IR-ში:

define i64 @myAdd(i64 %a, i64 %b) {
entry:
  %0 = add i64 %a, %b
  ret i64 %0
}

რაც შეგიძლიათ შეამჩნიოთ არის ის, რომ მიუხედავად იმისა, რომ აქ გამოიყენება სხვადასხვა სინტაქსური სტრუქტურები, ფუნქციის სტრუქტურა ძირითადად უცვლელია. LLVM IR კოდი ოდნავ უფრო ძლიერია ვიდრე Go SSA კოდი, C-ის მსგავსი. აქ, ფუნქციის დეკლარაციაში, ჯერ არის აღწერილობა მის მიერ დაბრუნებულ მონაცემთა ტიპზე, არგუმენტის ტიპი მითითებულია არგუმენტის სახელამდე. გარდა ამისა, IR ანალიზის გასამარტივებლად, გლობალური ერთეულების სახელებს წინ უძღვის სიმბოლო @და ადგილობრივი სახელების წინ არის სიმბოლო % (ფუნქცია ასევე განიხილება გლობალურ ერთეულად).

ერთი რამ, რაც უნდა აღინიშნოს ამ კოდთან დაკავშირებით, არის Go-ს ტიპის წარმომადგენლობის გადაწყვეტილება int, რომელიც შეიძლება წარმოდგენილი იყოს 32-ბიტიანი ან 64-ბიტიანი მნიშვნელობით, შემდგენელისა და კომპილაციის მიზნის მიხედვით, მიიღება, როდესაც LLVM აგენერირებს IR კოდს. ეს არის ერთ-ერთი მიზეზი იმისა, რომ LLVM IR კოდი არ არის, როგორც ბევრი ფიქრობს, პლატფორმაზე დამოუკიდებელი. ასეთი კოდი, რომელიც შექმნილია ერთი პლატფორმისთვის, არ შეიძლება უბრალოდ იქნას მიღებული და შედგენილი სხვა პლატფორმისთვის (თუ არ ხართ შესაფერისი ამ პრობლემის გადასაჭრელად უკიდურესი სიფრთხილით).

კიდევ ერთი საინტერესო პუნქტი, რომელიც უნდა აღინიშნოს, არის ის, რომ ტიპი i64 არ არის ხელმოწერილი მთელი რიცხვი: ის ნეიტრალურია რიცხვის ნიშნის წარმოდგენის თვალსაზრისით. ინსტრუქციის მიხედვით, მას შეუძლია წარმოადგინოს როგორც ხელმოწერილი, ასევე ხელმოუწერელი ნომრები. შეკრების ოპერაციის წარმოდგენის შემთხვევაში ამას მნიშვნელობა არ აქვს, ამიტომ არ არის განსხვავება ხელმოწერით ან ხელმოუწერელ რიცხვებთან მუშაობაში. აქვე მინდა აღვნიშნო, რომ C ენაში, ხელმოწერილი მთელი რიცხვის ცვლადის გადაჭარბება იწვევს განუსაზღვრელ ქცევას, ამიტომ Clang წინა ნაწილი ამატებს დროშას ოპერაციას. nsw (ხელმოწერილი შეფუთვა არ არის), რომელიც ეუბნება LLVM-ს, რომ მას შეუძლია ივარაუდოს, რომ დამატება არასდროს არ ავსებს.

ეს შეიძლება იყოს მნიშვნელოვანი ზოგიერთი ოპტიმიზაციისთვის. მაგალითად, ორი მნიშვნელობის დამატება i16 32-ბიტიან პლატფორმაზე (32-ბიტიანი რეგისტრებით) დამატებით მოითხოვს ნიშნის გაფართოების ოპერაციას, რათა დარჩეს დიაპაზონში i16. ამის გამო, ხშირად უფრო ეფექტურია მთელი რიცხვის ოპერაციების შესრულება მანქანების რეგისტრის ზომის მიხედვით.

რა მოხდება შემდეგ ამ IR კოდთან დაკავშირებით, ახლა ჩვენთვის განსაკუთრებული ინტერესი არ არის. კოდი ოპტიმიზირებულია (მაგრამ ჩვენს მსგავსი მარტივი მაგალითის შემთხვევაში, არაფერი ოპტიმიზირებულია) და შემდეგ გარდაიქმნება მანქანის კოდში.

მეორე მაგალითი

შემდეგი მაგალითი, რომელსაც ჩვენ განვიხილავთ, ცოტა უფრო რთული იქნება. კერძოდ, ჩვენ ვსაუბრობთ ფუნქციაზე, რომელიც აჯამებს მთელი რიცხვების ნაჭერს:

func sum(numbers []int) int {
    n := 0
    for i := 0; i < len(numbers); i++ {
        n += numbers[i]
    }
    return n
}

ეს კოდი გარდაიქმნება შემდეგ Go SSA კოდში:

func sum(numbers []int) int:
entry:
    jump for.loop
for.loop:
    t0 = phi [entry: 0:int, for.body: t6] #n                       int
    t1 = phi [entry: 0:int, for.body: t7] #i                       int
    t2 = len(numbers)                                              int
    t3 = t1 < t2                                                  bool
    if t3 goto for.body else for.done
for.body:
    t4 = &numbers[t1]                                             *int
    t5 = *t4                                                       int
    t6 = t0 + t5                                                   int
    t7 = t1 + 1:int                                                int
    jump for.loop
for.done:
    return t0

აქ უკვე შეგიძლიათ იხილოთ SSA ფორმაში კოდის წარმოდგენისთვის დამახასიათებელი მეტი კონსტრუქცია. ამ კოდის ალბათ ყველაზე აშკარა თვისებაა ის ფაქტი, რომ არ არსებობს სტრუქტურირებული ნაკადის კონტროლის ბრძანებები. გამოთვლების ნაკადის გასაკონტროლებლად არის მხოლოდ პირობითი და უპირობო ნახტომები, ხოლო თუ ამ ბრძანებას განვიხილავთ, როგორც დინების კონტროლის ბრძანებას, დაბრუნების ბრძანებას.

სინამდვილეში, აქ შეგიძლიათ ყურადღება მიაქციოთ იმ ფაქტს, რომ პროგრამა არ იყოფა ბლოკებად ხვეული ბრეკეტების გამოყენებით (როგორც C ენების ოჯახში). იგი დაყოფილია ეტიკეტებით, რომლებიც წააგავს ასამბლეის ენებს და წარმოდგენილია ძირითადი ბლოკების სახით. SSA-ში ძირითადი ბლოკები განისაზღვრება, როგორც კოდის მიმდებარე თანმიმდევრობა, რომელიც იწყება ლეიბლით და მთავრდება ძირითადი ბლოკის დასრულების ინსტრუქციებით, როგორიცაა - return и jump.

ამ კოდის კიდევ ერთი საინტერესო დეტალი წარმოდგენილია ინსტრუქციით phi. ინსტრუქციები საკმაოდ უჩვეულოა და შეიძლება გარკვეული დრო დასჭირდეს მის გაგებას. გვახსოვდეს, რომ SSA არის შემოკლება Static Single Assignment. ეს არის შემდგენლების მიერ გამოყენებული კოდის შუალედური წარმოდგენა, რომელშიც თითოეულ ცვლადს ენიჭება მნიშვნელობა მხოლოდ ერთხელ. ეს შესანიშნავია ჩვენი ფუნქციის მსგავსი მარტივი ფუნქციების გამოხატვისთვის myAddნაჩვენებია ზემოთ, მაგრამ არ არის შესაფერისი უფრო რთული ფუნქციებისთვის, როგორიცაა ამ ნაწილში განხილული ფუნქცია sum. კერძოდ, ცვლადები იცვლება მარყუჟის შესრულების დროს i и n.

SSA გვერდს უვლის ცვლადის მნიშვნელობების ერთხელ მინიჭების შეზღუდვას ე.წ. phi (მისი სახელი აღებულია ბერძნული ანბანიდან). ფაქტია, რომ იმისათვის, რომ კოდის SSA წარმოდგენა შეიქმნას ისეთი ენებისთვის, როგორიცაა C, თქვენ უნდა მიმართოთ რამდენიმე ხრიკს. ამ ინსტრუქციის გამოძახების შედეგი არის ცვლადის მიმდინარე მნიშვნელობა (i ან n), და მის პარამეტრებად გამოიყენება ძირითადი ბლოკების სია. მაგალითად, გაითვალისწინეთ ეს ინსტრუქცია:

t0 = phi [entry: 0:int, for.body: t6] #n

მისი მნიშვნელობა ასეთია: თუ წინა ძირითადი ბლოკი იყო ბლოკი entry (შეყვანა), შემდეგ t0 არის მუდმივი 0და თუ წინა ძირითადი ბლოკი იყო for.body, მაშინ თქვენ უნდა აიღოთ მნიშვნელობა t6 ამ ბლოკიდან. ეს ყველაფერი შეიძლება საკმაოდ იდუმალი ჩანდეს, მაგრამ ეს მექანიზმი არის ის, რაც აიძულებს SSA-ს მუშაობას. ადამიანის პერსპექტივიდან ეს ყველაფერი ართულებს კოდის გაგებას, მაგრამ ის ფაქტი, რომ თითოეული მნიშვნელობა მხოლოდ ერთხელ არის მინიჭებული, ბევრ ოპტიმიზაციას ბევრად აადვილებს.

გაითვალისწინეთ, რომ თუ თქვენ დაწერთ საკუთარ შემდგენელს, ჩვეულებრივ, არ მოგიწევთ საქმე ამ ტიპის საკითხებთან. კლანგიც კი არ ქმნის ყველა ამ ინსტრუქციას phi, ის იყენებს მექანიზმს alloca (ის წააგავს ჩვეულებრივ ლოკალურ ცვლადებთან მუშაობას). შემდეგ, LLVM ოპტიმიზაციის საშვის გაშვებისას გამოიძახეს mem2reg, ინსტრუქციები alloca გადაყვანილია SSA ფორმაში. თუმცა, TinyGo იღებს შეყვანას Go SSA-დან, რომელიც, მოხერხებულად, უკვე გადაკეთებულია SSA ფორმაში.

განსახილველი შუალედური კოდის ფრაგმენტის კიდევ ერთი ინოვაცია არის ის, რომ სლაიტის ელემენტებზე წვდომა ინდექსის მიხედვით წარმოდგენილია მისამართის გამოთვლის ოპერაციისა და მიღებული მაჩვენებლის გაუქმების ოპერაციის სახით. აქ შეგიძლიათ იხილოთ მუდმივების პირდაპირი დამატება IR კოდში (მაგალითად - 1:int). მაგალითში ფუნქციით myAdd ეს არ ყოფილა გამოყენებული. ახლა, როცა ეს ფუნქციები არ გვაქვს, მოდით შევხედოთ რა ხდება ეს კოდი LLVM IR ფორმაში გადაყვანისას:

define i64 @sum(i64* %ptr, i64 %len, i64 %cap) {
entry:
  br label %for.loop

for.loop:                                         ; preds = %for.body, %entry
  %0 = phi i64 [ 0, %entry ], [ %5, %deref.next ]
  %1 = phi i64 [ 0, %entry ], [ %6, %deref.next ]
  %2 = icmp slt i64 %1, %len
  br i1 %2, label %for.body, label %for.done

for.body:                                         ; preds = %for.loop
  %3 = getelementptr i64, i64* %ptr, i64 %1
  %4 = load i64, i64* %3
  %5 = add i64 %0, %4
  %6 = add i64 %1, 1
  br label %for.loop

for.done:                                         ; preds = %for.loop
  ret i64 %0
}

აქ, როგორც ადრე, შეგვიძლია დავინახოთ იგივე სტრუქტურა, რომელიც მოიცავს სხვა სინტაქსურ სტრუქტურებს. მაგალითად, ზარებში phi ღირებულებები და ეტიკეტები გაცვალეს. თუმცა აქ არის რაღაც, რაზეც განსაკუთრებული ყურადღების მიქცევა ღირს.

დასაწყისისთვის, აქ შეგიძლიათ ნახოთ სრულიად განსხვავებული ფუნქციის ხელმოწერა. LLVM არ უჭერს მხარს slices-ს და შედეგად, როგორც ოპტიმიზაცია, TinyGo შემდგენელმა, რომელმაც შექმნა ეს შუალედური კოდი, დაყო ამ მონაცემთა სტრუქტურის აღწერა ნაწილებად. ის შეიძლება წარმოადგენდეს სამ ნაჭერ ელემენტს (ptr, len и cap) როგორც სტრუქტურა (სტრუქტურა), მაგრამ მათი წარმოდგენა სამ ცალკეულ ერთეულებად იძლევა გარკვეული ოპტიმიზაციის საშუალებას. სხვა შემდგენელებმა შეიძლება წარმოადგინონ ნაჭერი სხვა გზით, რაც დამოკიდებულია სამიზნე პლატფორმის ფუნქციების გამოძახების კონვენციებზე.

ამ კოდის კიდევ ერთი საინტერესო თვისებაა ინსტრუქციის გამოყენება getelementptr (ხშირად შემოკლებით GEP).

ეს ინსტრუქცია მუშაობს პოინტერებთან და გამოიყენება სლაის ელემენტის მაჩვენებლის მისაღებად. მაგალითად, შევადაროთ C-ში დაწერილ შემდეგ კოდს:

int* sliceptr(int *ptr, int index) {
    return &ptr[index];
}

ან ამის შემდეგი ექვივალენტით:

int* sliceptr(int *ptr, int index) {
    return ptr + index;
}

აქ მთავარია ინსტრუქციები getelementptr არ ახორციელებს მოხსნის ოპერაციებს. ის უბრალოდ ითვლის ახალ მაჩვენებელს არსებულზე დაყრდნობით. ის შეიძლება იქნას მიღებული როგორც ინსტრუქცია mul и add ტექნიკის დონეზე. შეგიძლიათ მეტი წაიკითხოთ GEP ინსტრუქციების შესახებ აქ.

ამ შუალედური კოდის კიდევ ერთი საინტერესო თვისებაა ინსტრუქციის გამოყენება icmp. ეს არის ზოგადი დანიშნულების ინსტრუქცია, რომელიც გამოიყენება მთელი რიცხვების შედარების განსახორციელებლად. ამ ინსტრუქციის შედეგი ყოველთვის არის ტიპის მნიშვნელობა i1 - ლოგიკური ღირებულება. ამ შემთხვევაში შედარება ხდება საკვანძო სიტყვის გამოყენებით slt (ხელმოწერილია ნაკლები), რადგან ჩვენ ვადარებთ ორ რიცხვს, რომლებიც ადრე იყო წარმოდგენილი ტიპის მიხედვით int. თუ ჩვენ შევადარებთ ორ უსაზღვრო მთელ რიცხვს, მაშინ გამოვიყენებდით icmpდა შედარებაში გამოყენებული საკვანძო სიტყვა იქნება ult. მცურავი წერტილის რიცხვების შესადარებლად გამოიყენება სხვა ინსტრუქცია, fcmp, რომელიც მუშაობს ანალოგიურად.

შედეგები

მე მჯერა, რომ ამ მასალაში მე გავაშუქე LLVM IR-ის ყველაზე მნიშვნელოვანი მახასიათებლები. რა თქმა უნდა, აქ კიდევ ბევრია. კერძოდ, კოდის შუალედური წარმოდგენა შეიძლება შეიცავდეს ბევრ ანოტაციას, რომელიც საშუალებას აძლევს ოპტიმიზაციის პასს გაითვალისწინოს შემდგენლისთვის ცნობილი კოდის გარკვეული მახასიათებლები, რომლებიც სხვაგვარად არ შეიძლება იყოს გამოხატული IR-ში. მაგალითად, ეს არის დროშა inbounds GEP ინსტრუქციები, ან დროშები nsw и nuw, რომელიც შეიძლება დაემატოს ინსტრუქციებს add. იგივე ეხება საკვანძო სიტყვას private, რაც მიუთითებს ოპტიმიზატორზე, რომ მის მიერ მონიშნული ფუნქცია არ იქნება მითითებული მიმდინარე კომპილაციის ერთეულის გარედან. ეს საშუალებას იძლევა ბევრი საინტერესო ინტერპროცედურული ოპტიმიზაცია, როგორიცაა გამოუყენებელი არგუმენტების აღმოფხვრა.

შეგიძლიათ მეტი წაიკითხოთ LLVM-ის შესახებ აქ დოკუმენტაცია, რომელსაც ხშირად მიმართავთ თქვენი LLVM-ზე დაფუძნებული შემდგენელის შემუშავებისას. Აქ ხელმძღვანელობა, რომელიც უყურებს კომპილერის შემუშავებას ძალიან მარტივი ენისთვის. ინფორმაციის ორივე წყარო გამოგადგებათ საკუთარი შემდგენელის შექმნისას.

ძვირფასო მკითხველს! იყენებ LLVM-ს?

წყარო: www.habr.com