QBE - คอมไพเลอร์แบ็กเอนด์: เวอร์ชัน 1.3

 (c9x.me)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเพิ่ม การปรับแต่งประสิทธิภาพ ครั้งใหญ่มาก โดย QBE 1.3 ทำผลงานได้เกิน 63% ของประสิทธิภาพคอมไพเลอร์เชิงพาณิชย์บน vanilla coremark และดีขึ้น 33% เมื่อเทียบกับ qbe-1.2 ในชุดทดสอบของ Hare
  • QBE 1.3 เป็นรีลีสที่ใหญ่ที่สุดนับตั้งแต่ 1.0 โดยมีการ เพิ่มโค้ดราว 7k บรรทัด และลบออก 1.5k บรรทัด
  • การปรับแต่งใหม่รวมถึง GVN/GCM, การปรับแต่งลูป, การตัด if ออก, การทำ CFG ให้เรียบง่ายลง เป็นต้น แต่ยังคงเก็บไว้เฉพาะบางพาสที่ผ่านการพิสูจน์แล้ว
  • อินไลน์นิ่งถูกตัดออกจากชุดการปรับแต่งครั้งนี้ เนื่องจากมีปัญหาที่ไม่สอดคล้องกับ โมเดลคอมไพล์แบบสตรีมมิงระดับฟังก์ชัน ของ QBE
  • ใน coremark รุ่นดัดแปลงที่ทำ ee_isdigit ให้เป็นอินไลน์ และเปลี่ยน crcu8 เป็นอิมพลีเมนเทชันที่ง่ายกว่าและไม่มี branch นั้น QBE ไปถึงเป้าหมายที่ 70% ของประสิทธิภาพ gcc -O2
  • มีเครื่องมือ OCaml ใหม่ mgen ที่คอมไพล์แพตเทิร์น lispy IL ให้เป็นโค้ดจับคู่ในภาษา C ทำให้สามารถแทนที่หรือทำให้ลอจิกการเลือกคำสั่งที่เคยเขียนด้วยมือเรียบง่ายขึ้นได้
  • mgen จะค้นหาแพตเทิร์น IL ในบล็อกคอมเมนต์พิเศษแล้วแทรกโค้ด C ไว้ด้านล่างทันที โดยตัวอย่างการใช้งานปัจจุบันอยู่ที่ isel.c
  • การจับคู่ DAG ของคำสั่งใช้แนวทางการกำหนดหมายเลขที่คล้ายกับคอมไพเลอร์ Plan9 C ของ Ken Thompson และยังสร้างตัวจับคู่แบบไบต์โค้ดอย่างง่ายที่ runmatch() ใช้ตีความด้วย
  • เพิ่มการรองรับ Windows ABI แล้ว โดยส่ง -t amd64_win เพื่อคอมไพล์เป้าหมายสำหรับ Windows ได้
  • แอสเซมบลีที่ QBE สร้างยังคงเป็นไวยากรณ์แบบ AT&T และแนะนำให้คอมไพล์ด้วยแอสเซมเบลอร์ของ mingw
  • ปรับปรุงการรองรับโค้ดแบบไม่อิงตำแหน่ง ทำให้ลิงก์กับ shared object และสร้าง shared object ได้ลื่นไหลขึ้นบนเป้าหมายส่วนใหญ่
  • มีแฟลกค่าคงที่แบบไดนามิก extern ใหม่ (DYNCONST) เพื่อใช้แสดงการเข้าถึงทางอ้อมของ global symbol เช่นตัวแปรในไลบรารีไดนามิก ในระดับ IL

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • กำลังทำ OS ขนาดเล็กสไตล์ TRIPOS/Amiga Exec เป็นโปรเจกต์งานอดิเรกที่ทำมายาวนาน
    ไม่มีการป้องกันหน่วยความจำ ใช้แผนที่หน่วยความจำแบบแบน และการส่งข้อความก็อยู่ในระดับแค่ส่งพอยน์เตอร์กัน
    ถ้าจะทำให้ระบบแบบนี้โฮสต์ตัวเองได้ การมีคอมไพเลอร์ขนาดเล็กที่สร้าง PIE/PIC ได้จะสะดวกกว่ามาก ไลบรารีสไตล์ Amiga ก็ควรต้องเป็น PIC อยู่แล้ว และยังดีตรงที่เวลาเอาไฟล์ปฏิบัติการไปวางไว้ตรงไหนสักแห่งใน shared memory map ก็ไม่ต้องแพตช์ตอนโหลดมากนัก
    GCC กับ Clang ก็ทำได้ แต่ใหญ่เกินไป ครั้งล่าสุดที่เช็ก TCC ยังทำ PIC ไม่ได้ คงต้องลองดู QBE เพิ่ม

    • C compiler ของฉันสร้าง PIC ได้ เผื่อจะสนใจ: https://codeberg.org/lsof/antcc/
      หวังว่าจะไม่ฟังดูเหมือนโปรโมตตัวเองนะ ฉันชอบวงการคอมไพเลอร์ขนาดเล็กมากจริง ๆ และมันยังต้องการการทดสอบอีกเยอะ
    • ฉันก็กำลังทำ Ashet OS ซึ่งเป็น OS ที่ใช้แผนที่หน่วยความจำแบบแบน ทุกอย่างเป็น PIE และ system call เป็น function call
      ไปได้ค่อนข้างไกลแล้ว และรองรับหลายแพลตฟอร์ม
      แต่คงยากที่จะไปถึงขั้นโฮสต์ตัวเองได้ในเร็ว ๆ นี้ เพราะต้องมี การสร้างโค้ด Thumb-2 และในทางปฏิบัติก็แทบมีทางเดียวคือต้องเขียนคอมไพเลอร์เอง อีกข้อจำกัดคือมี RAM ใช้งานได้แค่ 8MB ไม่นับโค้ดเคอร์เนล
      ใช้ฟอร์แมตไฟล์ปฏิบัติการของตัวเองชื่อ .ashex ซึ่งสร้างมาจากการแปลงไฟล์ ELF ในกระบวนการนี้จะกิน special section ที่โดยพื้นฐานแล้วมี absolute jump แค่อันเดียว และ app loader จะเขียนทับใหม่ให้เป็นที่อยู่ system call จริง
      ความยากของระบบหน่วยความจำแบบแบนคือการรองรับ shared object ให้เรียบร้อย ถ้าจะให้แชร์โค้ดกันระหว่างแอปต่าง ๆ ได้ ก็ต้องมีการรองรับจากคอมไพเลอร์เพื่อให้การเข้าถึง dynamic symbol ทั้งหมดทำผ่านตัวแปรที่เก็บไว้ในรีจิสเตอร์

  • ดีใจมากที่มี คีย์เวิร์ด extern ใหม่
    ใน release note ไม่ได้พูดถึง แต่สิ่งนี้ทำงานร่วมกับ thread ด้วย ทำให้ใช้ initial-exec TLS ได้ จำเป็นเวลาต้องเข้าถึงตัวแปร global แบบ thread-local ที่ถูกนิยามใน shared library อื่น และ FreeBSD ก็ต้องใช้ใน ctype.h
    extern ยังจำเป็นบนแพลตฟอร์มอย่าง macOS หรือ Haiku เวลาเข้าถึงตัวแปร global ปกติใน shared library เช่น stderr ด้วย ตอนนี้คอมไพเลอร์ที่อิง QBE จะรองรับระบบปฏิบัติการและกรณีใช้งานได้มากขึ้นมาก
    ขอบคุณ Roland มากสำหรับ การปรับปรุงประสิทธิภาพ ด้วย ทำงานได้ยอดเยี่ยมจริง ๆ

  • ถ้าอ่านถูก นี่คือมี การรองรับ Windows อย่างเป็นทางการ แล้วใช่ไหม?
    นี่ไม่ใช่หนึ่งในข้อจำกัดใหญ่ของ QBE ทั้งในอดีตและจนถึงตอนนี้หรอกหรือ? ดีใจมากที่ได้เห็น

  • เป้าหมายของโปรเจกต์นี้ทับซ้อนกับ Cranelift ไหม? ยังไม่ค่อยเห็นภาพว่าควรใช้ QBE ตอนไหน

    • QBE คล้าย “OpenBSD” ของโลก compiler backend มันมีปรัชญาเรื่องความเรียบง่ายและมินิมัลลิสม์ และตาม คำอธิบายอย่างเป็นทางการ เป้าหมายคือ “ให้ประสิทธิภาพ 70% ของคอมไพเลอร์ออปติไมซ์ระดับอุตสาหกรรม ด้วยโค้ดเพียง 10%”
      คู่แข่งจริง ๆ คือ Cranelift และ LLVM
      น่าเสียดายว่าในอดีตมันถูกใช้ mostly ในภาษางานอดิเรกหรือการทำคอมไพเลอร์เพื่อการทดลอง เช่น myrddin ที่ดูเหมือนภาษาในตระกูล C แบบใหม่ แต่ตอนนี้น่าจะตายไปแล้ว ส่วน cproc ยังเป็นอิมพลีเมนเทชัน C compiler สำหรับงานอดิเรกที่ยังมีชีวิตอยู่
      แต่หลังจาก Hare เลือกใช้ QBE ก็เริ่มมีความหวัง คำตอบของคำถามนี้อยู่ที่นี่: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
    • ฉันมองว่าเป้าหมายทับซ้อนทั้งกับ Cranelift และ LLVM
      ไม่ได้รู้ลึกมาก แต่มีข้อมูลเปรียบเทียบอยู่เยอะ เท่าที่รู้ QBE มุ่งเป็น backend ที่เรียบง่ายกว่า อีกสองตัวมาก

  • วิธีใช้ DSL ขนาดเล็กเพื่อสร้าง instruction selection matcher นี่เท่มาก