نمای خط زمانی (Timeline View)

نمای خط زمانی گزارش دقیقی از انتقال وضعیت هر دستورالعمل درون خط‌لولهٔ (pipeline) دستورالعمل تولید می‌کند. این نما با گزینهٔ خط فرمان -timeline فعال می‌شود. هم‌زمان با انتقال دستورالعمل‌ها از مراحل مختلف خط‌لوله، وضعیت آن‌ها در گزارش نما به تصویر کشیده می‌شود. این وضعیت‌ها با نویسه‌های زیر نمایش داده می‌شوند:

در زیر نمای خط زمانی برای زیرمجموعه‌ای از مثال dot-product واقع در test/tools/llvm-mca/X86/BtVer2/dot-product.s آمده است که توسط llvm-mca با دستور زیر پردازش شده است:

$ llvm-mca -mtriple=x86_64-unknown-unknown -mcpu=btver2 -iterations=3 -timeline dot-product.s

Timeline view:
                    012345
Index     0123456789
[0,0]     DeeER.    .    .   vmulps   %xmm0, %xmm1, %xmm2
[0,1]     D==eeeER  .    .   vhaddps  %xmm2, %xmm2, %xmm3
[0,2]     .D====eeeER    .   vhaddps  %xmm3, %xmm3, %xmm4
[1,0]     .DeeE-----R    .   vmulps   %xmm0, %xmm1, %xmm2
[1,1]     . D=eeeE---R   .   vhaddps  %xmm2, %xmm2, %xmm3
[1,2]     . D====eeeER   .   vhaddps  %xmm3, %xmm3, %xmm4
[2,0]     .  DeeE-----R  .   vmulps   %xmm0, %xmm1, %xmm2
[2,1]     .  D====eeeER  .   vhaddps  %xmm2, %xmm2, %xmm3
[2,2]     .   D======eeeER   vhaddps  %xmm3, %xmm3, %xmm4
Average Wait times (based on the timeline view):
[0]: Executions
[1]: Average time spent waiting in a scheduler's queue
[2]: Average time spent waiting in a scheduler's queue while ready
[3]: Average time elapsed from WB until retire stage
      [0]    [1]    [2]    [3]
0.     3     1.0    1.0    3.3       vmulps   %xmm0, %xmm1, %xmm2
1.     3     3.3    0.7    1.0       vhaddps  %xmm2, %xmm2, %xmm3
2.     3     5.7    0.0    0.0       vhaddps  %xmm3, %xmm3, %xmm4
       3     3.3    0.5    1.4       <total>

نمای خط زمانی جالب توجه است زیرا تغییرات وضعیت دستورالعمل را در حین اجرا نشان می‌دهد. همچنین دیدگاهی دربارهٔ نحوهٔ پردازش دستورالعمل‌های اجراشده روی هدف توسط ابزار و چگونگی محاسبهٔ اطلاعات زمان‌بندی آن‌ها فراهم می‌کند.

نمای خط زمانی در دو جدول سازمان‌دهی شده است. جدول اول تغییر وضعیت دستورالعمل‌ها را در طول زمان (اندازه‌گیری‌شده بر حسب چرخه) نشان می‌دهد؛ جدول دوم (با نام Average Wait times) آمارهای زمان‌بندی مفیدی را گزارش می‌کند که به عیب‌یابی گلوگاه‌های کارایی ناشی از وابستگی‌های داده‌ای طولانی و استفادهٔ غیربهینه از منابع سخت‌افزاری کمک می‌کند.

هر دستورالعمل در نمای خط زمانی با یک جفت اندیس مشخص می‌شود، که اندیس اول تکرار (iteration) را مشخص می‌کند و اندیس دوم شناسهٔ دستورالعمل است (یعنی مکانی که در توالی کد ظاهر می‌شود). از آنجا که این مثال با استفاده از ۳ تکرار تولید شده است: -iterations=3، اندیس‌های تکرار شامل بازهٔ ۰ تا ۲ می‌شوند.

به‌استثنای ستون اول و آخر، بقیهٔ ستون‌ها بر حسب چرخه هستند. چرخه‌ها به‌صورت متوالی و با شروع از ۰ شماره‌گذاری شده‌اند.

از خروجی نمونهٔ بالا، موارد زیر را درمی‌یابیم:

دستورالعمل [1,0] (یعنی vmulps از تکرار شمارهٔ ۱) نیازی به انتظار در صف زمان‌بند (scheduler) برای در دسترس قرار گرفتن عملوندها ندارد. تا زمانی که vmulps اعزام می‌شود، عملوندها از قبل در دسترس هستند و خط‌لولهٔ JFPU1 آمادهٔ ارائهٔ خدمات به دستورالعمل دیگری است. بنابراین دستورالعمل می‌تواند بلافاصله در خط‌لولهٔ JFPU1 صادر شود (issued). این موضوع با این واقعیت نشان داده می‌شود که دستورالعمل تنها ۱ چرخه (1cy) را در صف زمان‌بند سپری کرده است.

فاصله‌ای ۵ چرخه‌ای بین مرحلهٔ بازنویسی (write-back) و رویداد بازنشستگی (retire) وجود دارد. این به این دلیل است که دستورالعمل‌ها باید به ترتیب برنامه بازنشسته شوند، بنابراین [1,0] باید منتظر بماند تا ابتدا [0,2] بازنشسته شود (یعنی باید تا چرخهٔ ۱۰ صبر کند).

در این مثال، همهٔ دستورالعمل‌ها در یک زنجیرهٔ وابستگی RAW (خواندن پس از نوشتن یا Read After Write) قرار دارند. ثبات %xmm2 که توسط vmulps نوشته می‌شود بلافاصله توسط اولین vhaddps استفاده می‌شود، و ثبات %xmm3 که توسط اولین vhaddps نوشته می‌شود توسط دومین vhaddps استفاده می‌گردد. وابستگی‌های طولانی داده‌ها تأثیر منفی بر ILP (موازی‌سازی در سطح دستورالعمل یا Instruction Level Parallelism) دارند.

در مثال dot-product، پادوابستگی‌هایی (anti-dependencies) وجود دارند که توسط دستورالعمل‌های تکرارهای مختلف ایجاد شده‌اند. با این حال، این وابستگی‌ها را می‌توان در مرحلهٔ تغییر نام ثبات‌ها (register renaming) حذف کرد (به بهای تخصیص نام‌های مستعار ثبات و در نتیجه مصرف ثبات‌های فیزیکی).

جدول Average Wait times به عیب‌یابی مشکلات کارایی ناشی از وجود دستورالعمل‌های با تاخیر بالا (long latency) و وابستگی‌های بالقوه طولانی داده‌ها که ممکن است ILP را محدود کنند، کمک می‌کند. سطر آخر، <total>، میانگین کلی تمام دستورالعمل‌های اندازه‌گیری‌شده را نشان می‌دهد. توجه داشته باشید که llvm-mca به‌طور پیش‌فرض، دست‌کم ۱ چرخه (1cy) را بین رویداد اعزام (dispatch) و رویداد صدور (issue) فرض می‌کند.

هنگامی که کارایی به دلیل وابستگی‌های داده یا دستورالعمل‌های با تاخیر طولانی محدود می‌شود، انتظار می‌رود تعداد چرخه‌های سپری‌شده در وضعیت ready در مقایسه با کل چرخه‌های سپری‌شده در صف زمان‌بند بسیار اندک باشد. تفاوت میان این دو شمارنده معیار مناسبی از میزان اثرگذاری وابستگی‌های داده بر اجرای دستورالعمل‌ها است. زمانی که کارایی عمدتاً به دلیل کمبود منابع سخت‌افزاری محدود شود، اختلاف بین این دو شمارنده ناچیز است. با این حال، تعداد چرخه‌های سپری‌شده در صف معمولاً بیشتر خواهد بود (یعنی بیش از ۱ تا ۳ چرخه - 1-3cy)، به‌ویژه در مقایسه با سایر دستورالعمل‌های با تاخیر اندک..SS تحلیل گلوگاه (Bottleneck Analysis)

گزینه خط فرمان -bottleneck-analysis تحلیل گلوگاه‌های کارایی را فعال می‌کند.

این تحلیل می‌تواند پرهزینه باشد. این فرایند تلاش می‌کند افزایش فشار بر بخش انتهایی (backend pressure، ناشی از فشار بر منابع خط لوله و وابستگی‌های داده) را با توقف‌های اعزام پویا (dynamic dispatch stalls) مرتبط سازد.

در زیر نمونه‌ای از خروجی -bottleneck-analysis آورده شده است که توسط llvm-mca برای ۵۰۰ تکرار از مثال ضرب داخلی (dot-product) بر روی btver2 تولید شده است.

Cycles with backend pressure increase [ 48.07% ]
Throughput Bottlenecks:
  Resource Pressure       [ 47.77% ]
  - JFPA  [ 47.77% ]
  - JFPU0  [ 47.77% ]
  Data Dependencies:      [ 0.30% ]
  - Register Dependencies [ 0.30% ]
  - Memory Dependencies   [ 0.00% ]
Critical sequence based on the simulation:
              Instruction                         Dependency Information
 +----< 2.    vhaddps %xmm3, %xmm3, %xmm4
 |
 |    < loop carried >
 |
 |      0.    vmulps  %xmm0, %xmm1, %xmm2
 +----> 1.    vhaddps %xmm2, %xmm2, %xmm3         ## RESOURCE interference:  JFPA [ probability: 74% ]
 +----> 2.    vhaddps %xmm3, %xmm3, %xmm4         ## REGISTER dependency:  %xmm3
 |
 |    < loop carried >
 |
 +----> 1.    vhaddps %xmm2, %xmm2, %xmm3         ## RESOURCE interference:  JFPA [ probability: 74% ]

بر اساس این تحلیل، توان عملیاتی (throughput) به دلیل فشار منابع محدود شده است، نه به دلیل وابستگی‌های داده. این تحلیل، افزایش فشار بخش انتهایی (backend) را در طول ۴۸٫۰۷٪ از اجرای شبیه‌سازی‌شده مشاهده کرده است. تقریباً تمام این رویدادهای افزایش فشار، به دلیل رقابت (contention) بر سر منابع پردازنده JFPA/JFPU0 رخ داده‌اند.

توالی critical sequence (توالی بحرانی) پرهزینه‌ترین دنباله دستورالعمل‌ها بر اساس شبیه‌سازی است. این دنباله نشانه‌گذاری شده است تا اطلاعات بیشتری درباره وابستگی‌های بحرانی ثبات‌ها و تداخل منابع بین دستورالعمل‌ها ارائه دهد.

انتظار می‌رود دستورالعمل‌های موجود در توالی بحرانی تأثیر چشمگیری بر کارایی داشته باشند. به لحاظ ساختاری، دقت این تحلیل به‌شدت به شبیه‌سازی و (همانند همیشه) کیفیت مدل پردازنده در llvm وابسته است.

تحلیل گلوگاه در حال حاضر برای پردازنده‌های دارای بخش انتهایی ترتیبی (in-order backend) پشتیبانی نمی‌شود.

آمارهای تکمیلی برای تشخیص بیشتر مشکلات کارایی (Extra Statistics to Further Diagnose Performance Issues)

گزینه خط فرمان -all-stats آمار تکمیلی و شمارنده‌های کارایی را برای منطق اعزام (dispatch logic)، بافر بازآرایی (reorder buffer)، واحد کنترل بازنشستگی (retire control unit)، و پرونده ثبات‌ها (register file) فعال می‌کند.

در زیر نمونه‌ای از خروجی -all-stats تولیدشده توسط llvm-mca برای ۳۰۰ تکرار از مثال ضرب داخلی (dot-product) که در بخش‌های پیشین بررسی شد، آورده شده است.

Dynamic Dispatch Stall Cycles:
RAT     - Register unavailable:                      0
RCU     - Retire tokens unavailable:                 0
SCHEDQ  - Scheduler full:                            272  (44.6%)
LQ      - Load queue full:                           0
SQ      - Store queue full:                          0
GROUP   - Static restrictions on the dispatch group: 0
Dispatch Logic - number of cycles where we saw N micro opcodes dispatched:
[# dispatched], [# cycles]
 0,              24  (3.9%)
 1,              272  (44.6%)
 2,              314  (51.5%)
Schedulers - number of cycles where we saw N micro opcodes issued:
[# issued], [# cycles]
 0,          7  (1.1%)
 1,          306  (50.2%)
 2,          297  (48.7%)
Scheduler's queue usage:
[1] Resource name.
[2] Average number of used buffer entries.
[3] Maximum number of used buffer entries.
[4] Total number of buffer entries.
 [1]            [2]        [3]        [4]
JALU01           0          0          20
JFPU01           17         18         18
JLSAGU           0          0          12
Retire Control Unit - number of cycles where we saw N instructions retired:
[# retired], [# cycles]
 0,           109  (17.9%)
 1,           102  (16.7%)
 2,           399  (65.4%)
Total ROB Entries:                64
Max Used ROB Entries:             35  ( 54.7% )
Average Used ROB Entries per cy:  32  ( 50.0% )
Register File statistics:
Total number of mappings created:    900
Max number of mappings used:         35
*  Register File #1 -- JFpuPRF:
   Number of physical registers:     72
   Total number of mappings created: 900
   Max number of mappings used:      35
*  Register File #2 -- JIntegerPRF:
   Number of physical registers:     64
   Total number of mappings created: 0
   Max number of mappings used:      0

اگر به جدول Dynamic Dispatch Stall Cycles نگاه کنیم، می‌بینیم که شمارنده مربوط به SCHEDQ مقدار ۲۷۲ چرخه را گزارش می‌دهد. این شمارنده هر بار که منطق اعزام به دلیل پر بودن صف زمان‌بند (scheduler) نتواند یک گروه کامل را اعزام کند، افزایش می‌یابد.

با نگاه به جدول Dispatch Logic، مشاهده می‌کنیم که خط لوله تنها در ۵۱٫۵٪ مواقع قادر به اعزام دو ریزکد دستوری (micro opcode) بوده است. گروه اعزام در ۴۴٫۶٪ چرخه‌ها به یک ریزکد دستوری محدود شد که معادل ۲۷۲ چرخه است. آمارهای اعزام با استفاده از گزینه دستوری -all-stats یا -dispatch-stats قابل نمایش هستند.

جدول بعدی، یعنی Schedulers، نموداری هیستوگرام ارائه می‌دهد که تعداد ریزکدهای دستوری صادرشده (issued) در تعداد مشخصی از چرخه‌ها را نشان می‌دهد. در این حالت، از ۶۱۰ چرخه شبیه‌سازی‌شده، ۳۰۶ بار (۵۰٫۲٪) ریزکدهای تکی صادر شده و در ۷ چرخه هیچ ریزکدی صادر نشده است.

جدول Scheduler's queue usage میانگین و حداکثر تعداد مدخل‌های بافر (یعنی مدخل‌های صف زمان‌بند) استفاده‌شده در زمان اجرا را نشان می‌دهد. منبع JFPU01 به حداکثر ظرفیت خود رسیده است (۱۸ از ۱۸ مدخل صف). توجه داشته باشید که AMD Jaguar سه زمان‌بند را پیاده‌سازی می‌کند:

هسته ضرب داخلی (dot-product) متشکل از سه دستورالعمل ممیز شناور است (یک ضرب برداری و به دنبال آن دو جمع افقی). این امر مشخص می‌کند چرا به نظر می‌رسد تنها از زمان‌بند ممیز شناور استفاده شده است.

پر شدن صف زمان‌بند، یا ناشی از زنجیره‌های وابستگی داده است یا استفاده غیربهینه از منابع سخت‌افزاری. گاهی اوقات، فشار منابع را می‌توان با بازنویسی هسته پردازشی (kernel) و استفاده از دستورالعمل‌های متفاوت که منابع زمان‌بند متفاوتی را مصرف می‌کنند، کاهش داد. زمان‌بندهای با صف کوچک در برابر گلوگاه‌های ناشی از وجود وابستگی‌های طولانی داده انعطاف‌پذیری کمتری دارند. آمارهای زمان‌بند با استفاده از گزینه دستوری -all-stats یا -scheduler-stats نمایش داده می‌شوند.

جدول بعدی، Retire Control Unit، هیستوگرامی را نشان می‌دهد که تعداد دستورالعمل‌های بازنشسته‌شده (retired) در تعداد مشخصی چرخه را نشان می‌دهد. در این حالت، از ۶۱۰ چرخه شبیه‌سازی‌شده، ۳۹۹ بار (۶۵٫۴٪) دو دستورالعمل در طی یک چرخه بازنشسته شده‌اند و در ۱۰۹ چرخه هیچ دستورالعملی بازنشسته نشده است. آمارهای بازنشستگی با استفاده از گزینه دستوری -all-stats یا -retire-stats نمایش داده می‌شوند.

آخرین جدول ارائه‌شده، Register File statistics است. هر پرونده ثبات فیزیکی (PRF) مورد استفاده توسط خط لوله در این جدول نشان داده شده است. در پردازنده AMD Jaguar دو پرونده ثبات وجود دارد: یکی برای ثبات‌های ممیز شناور (JFpuPRF) و دیگری برای ثبات‌های عدد صحیح (JIntegerPRF). این جدول نشان می‌دهد که از ۹۰۰ دستورالعمل پردازش‌شده، ۹۰۰ نگاشت ایجاد شده است. از آنجا که این نمونه ضرب داخلی تنها از ثبات‌های ممیز شناور استفاده کرده است، JFpuPRF مسئول ایجاد ۹۰۰ نگاشت بوده است. با این حال، مشاهده می‌کنیم که خط لوله در هر زمان مشخص حداکثر از ۳۵ مدخل از ۷۲ مدخل ثبات موجود استفاده کرده است. می‌توان نتیجه گرفت که PRF ممیز شناور تنها پرونده ثبات استفاده‌شده برای این مثال بوده و هرگز دچار کمبود منبع نشده است. آمارهای پرونده ثبات با استفاده از گزینه دستوری -all-stats یا -register-file-stats نمایش داده می‌شوند..sp در این مثال، می‌توان نتیجه گرفت که IPC عمدتاً به‌دلیل وابستگی‌های داده‌ای محدود شده است، نه فشار بر منابع.

جریان دستورالعمل (Instruction Flow)

این بخش جریان دستورالعمل را در خط لولهٔ پیش‌فرض llvm-mca و همچنین واحدهای عملیاتی درگیر در این فرایند شرح می‌دهد.

خط لولهٔ پیش‌فرض، توالی مراحل زیر را برای پردازش دستورالعمل‌ها پیاده‌سازی می‌کند:

خط لولهٔ ترتیبی (in-order) توالی مراحل زیر را پیاده‌سازی می‌کند:

ابزار llvm-mca فرض می‌کند که تمام دستورالعمل‌ها پیش از آغاز شبیه‌سازی رمزگشایی شده و درون یک صف قرار گرفته‌اند. بنابراین، مراحل واکشی و رمزگشایی دستورالعمل مدل‌سازی نمی‌شوند. گلوگاه‌های کارایی در بخش پیشین (frontend) شناسایی نمی‌شوند. همچنین، llvm-mca پیش‌بینی پرش (branch prediction) را مدل‌سازی نمی‌کند.

اعزام دستورالعمل (Instruction Dispatch)

در طول مرحلهٔ اعزام، دستورالعمل‌ها به ترتیب برنامه از صف دستورالعمل‌های از پیش رمزگشایی‌شده برداشته می‌شوند و به‌صورت گروهی به زمان‌بندهای سخت‌افزاری شبیه‌سازی‌شده اعزام می‌گردند.

اندازهٔ یک گروه اعزام به در دسترس بودن منابع سخت‌افزاری شبیه‌سازی‌شده بستگی دارد. پهنای اعزام پردازنده به‌طور پیش‌فرض برابر با مقدار IssueWidth در مدل زمان‌بندی LLVM است.

یک دستورالعمل در صورتی می‌تواند اعزام شود که:

مدل‌های زمان‌بندی می‌توانند به‌صورت اختیاری مشخص کنند چه فایل‌های ثباتی (register files) روی پردازنده موجود است. llvm-mca از این اطلاعات برای مقداردهی اولیهٔ توصیف‌گرهای فایل ثبات استفاده می‌کند. کاربران می‌توانند با استفاده از گزینهٔ خط فرمان -register-file-size تعداد ثبات‌های فیزیکی را که به‌صورت سراسری برای تغییر نام ثبات‌ها موجود هستند، محدود کنند. مقدار صفر برای این گزینه به معنای نامحدود است. با دانستن اینکه چه تعداد ثبات برای تغییر نام در دسترس است، این ابزار می‌تواند توقف‌های اعزام (dispatch stalls) ناشی از کمبود ثبات‌های فیزیکی را پیش‌بینی کند.

تعداد ورودی‌های بافر بازترتیب که توسط یک دستورالعمل مصرف می‌شود، به تعداد ریزکدها (micro-opcodes) مشخص‌شده برای آن دستورالعمل توسط مدل زمان‌بندی مقصد بستگی دارد. بافر بازترتیب مسئول ردیابی پیشرفت دستورالعمل‌های "در حال اجرا" ("in-flight") و بازنشسته کردن آن‌ها به ترتیب برنامه است. تعداد ورودی‌های بافر بازترتیب به‌طور پیش‌فرض برابر با مقدار تعیین‌شده توسط فیلد MicroOpBufferSize در مدل زمان‌بندی مقصد است.

دستورالعمل‌هایی که به زمان‌بندها اعزام می‌شوند، ورودی‌های بافر زمان‌بند را مصرف می‌کنند. llvm-mca مدل زمان‌بندی را پرس‌وجو می‌کند تا مجموعه منابع بافرشدهٔ مصرفی توسط یک دستورالعمل را مشخص نماید. با منابع بافرشده همانند منابع زمان‌بند رفتار می‌شود.

صدور دستورالعمل (Instruction Issue)

هر زمان‌بند پردازنده یک بافر از دستورالعمل‌ها را پیاده‌سازی می‌کند. یک دستورالعمل باید در بافر زمان‌بند منتظر بماند تا عملوندهای ثبات ورودی آن در دسترس قرار گیرند. تنها در آن نقطه است که دستورالعمل واجد شرایط اجرا می‌شود و ممکن است برای اجرا (احتمالاً خارج از نوبت یا out-of-order) صادر گردد. تاخیرهای دستورالعمل توسط llvm-mca و به کمک مدل زمان‌بندی محاسبه می‌شوند.

زمان‌بند llvm-mca برای شبیه‌سازی چندین زمان‌بند پردازنده طراحی شده است. این زمان‌بند مسئول ردیابی وابستگی‌های داده‌ای و انتخاب پویای منابع پردازنده است که توسط دستورالعمل‌ها مصرف می‌شوند. این بخش مدیریت واحدهای منابع پردازنده و گروه‌های منابع را به یک مدیر منابع واگذار می‌کند. مدیر منابع مسئول انتخاب واحدهای منبعی است که توسط دستورالعمل‌ها مصرف می‌شوند. برای مثال، اگر یک دستورالعمل 1cy از یک گروه منابع را مصرف کند، مدیر منابع یکی از واحدهای دردسترس از آن گروه را انتخاب می‌کند؛ به‌طور پیش‌فرض، مدیر منابع از یک گزینش‌گر نوبت‌گردشی (round-robin) استفاده می‌کند تا تضمین نماید مصرف منابع به‌طور یکنواخت میان تمام واحدهای یک گروه توزیع می‌شود.

زمان‌بند llvm-mca در داخل خود دستورالعمل‌ها را به سه دسته گروه‌بندی می‌کند:

بسته به در دسترس بودن عملوندها، دستورالعمل‌هایی که به زمان‌بند اعزام می‌شوند یا در WaitSet یا در ReadySet قرار می‌گیرند.

در هر چرخه، زمان‌بند بررسی می‌کند که آیا دستورالعمل‌ها می‌توانند از WaitSet به ReadySet منتقل شوند، و آیا دستورالعمل‌های موجود در ReadySet می‌توانند به خطوط لولهٔ زیرین صادر شوند یا خیر. این الگوریتم دستورالعمل‌های قدیمی‌تر را نسبت به دستورالعمل‌های جدیدتر در اولویت قرار می‌دهد..SS مرحله بازنویسی و بازنشستگی (Write-Back and Retire Stage)

دستورالعمل‌های صادرشده از ReadySet به IssuedSet منتقل می‌شوند. در آنجا، دستورالعمل‌ها تا زمان رسیدن به مرحله بازنویسی (write-back) منتظر می‌مانند. در آن نقطه، آن‌ها از صف حذف شده و به واحد کنترل بازنشستگی (retire control unit) اطلاع داده می‌شود.

هنگامی که دستورالعمل‌ها اجرا می‌شوند، واحد کنترل بازنشستگی دستورالعمل را با پرچم "ready to retire" (آماده برای بازنشستگی) نشانه‌گذاری می‌کند.

دستورالعمل‌ها به ترتیب برنامه (program order) بازنشسته می‌شوند. بازنشستگی به فایل ثبات (register file) اطلاع داده می‌شود تا بتواند ثبات‌های فیزیکی را که در طول مرحله تغییر نام ثبات برای دستورالعمل تخصیص داده شده بودند، آزاد کند.

واحد بارگذاری/ذخیره‌سازی و مدل سازگاری حافظه (Load/Store Unit and Memory Consistency Model)

برای شبیه‌سازی اجرای خارج از نوبت عملیات‌های حافظه، llvm-mca از یک واحد بارگذاری/ذخیره‌سازی شبیه‌سازی‌شده (LSUnit) برای شبیه‌سازی اجرای حدسی بارگذاری‌ها و ذخیره‌سازی‌ها بهره می‌برد.

هر بارگذاری (یا ذخیره‌سازی) یک مدخل را در صف بارگذاری (یا ذخیره‌سازی) مصرف می‌کند. کاربران می‌توانند پرچم‌های -lqueue و -squeue را به ترتیب برای محدود کردن تعداد مدخل‌ها در صف‌های بارگذاری و ذخیره‌سازی مشخص کنند. صف‌ها به‌طور پیش‌فرض نامحدود هستند.

واحد LSUnit یک مدل سازگاری سست (relaxed consistency) را برای بارگذاری‌ها و ذخیره‌سازی‌های حافظه پیاده‌سازی می‌کند. قوانین عبارتند از:

به‌طور پیش‌فرض، LSUnit با خوش‌بینی فرض می‌کند که بارگذاری‌ها با عملیات ذخیره‌سازی هم‌پوشانی آدرس ندارند (-noalias=true). با این فرض، بارگذاری‌های جدیدتر همواره مجازند از ذخیره‌سازی‌های قدیمی‌تر عبور کنند. در اصل، LSUnit هیچ تحلیلی برای تفکیک هم‌پوشانی آدرس‌ها (alias analysis) اجرا نمی‌کند تا پیش‌بینی کند چه زمانی بارگذاری‌ها و ذخیره‌سازی‌ها با یکدیگر تداخل ندارند.

توجه داشته باشید که در مورد حافظه ترکیبی نوشتاری (write-combining)، قانون شماره ۳ می‌تواند برای مجاز دانستن تغییر ترتیب عملیات ذخیره‌سازی غیرهم‌پوشان تعدیل شود. با این وجود، در حال حاضر هیچ راهی برای سست‌تر کردن بیشتر مدل حافظه وجود ندارد (-noalias تنها گزینه است). اساساً، گزینه‌ای برای تعیین نوع حافظه متفاوت (مانند write-back، write-combining، write-through و غیره) و در نتیجه ضعیف‌تر یا قوی‌تر کردن مدل حافظه ارائه نشده است.

سایر محدودیت‌ها عبارتند از:

واحد LSUnit تلاشی برای پیش‌بینی اینکه آیا یک بارگذاری یا ذخیره‌سازی در حافظه نهان L1 با برخورد (hit) مواجه می‌شود یا خطا (miss)، انجام نمی‌دهد. این واحد تنها می‌داند که آیا یک دستورالعمل "MayLoad" و/یا "MayStore" هست یا خیر. برای بارگذاری‌ها، مدل زمان‌بندی یک تأخیر "خوش‌بینانه" از بارگذاری تا استفاده (load-to-use) ارائه می‌دهد (که معمولاً با تأخیر load-to-use در صورت برخورد در L1D مطابقت دارد).

ابزار llvm-mca (به‌تنهایی) اطلاعی از عملیات ترتیبی‌ساز یا دستورالعمل‌های مشابه سد حافظه ندارد. واحد LSUnit در گذشته به‌طور محافظه‌کارانه‌ای از پرچم‌های "MayLoad"، "MayStore" و اثرات جانبی مدل‌سازی‌نشده دستورالعمل استفاده می‌کرد تا تعیین کند آیا یک دستورالعمل باید به‌عنوان یک سد حافظه در نظر گرفته شود یا خیر. این رویکرد در کل نادقیق بود و تغییر یافت؛ به‌گونه‌ای که اکنون هر دستورالعمل دارای پرچم‌های IsAStoreBarrier و IsALoadBarrier است. این پرچم‌ها مختص mca بوده و به‌طور پیش‌فرض برای هر دستورالعمل برابر با false هستند. اگر نیاز باشد برای هر دستورالعملی یکی از این پرچم‌ها تنظیم شود، این کار باید در کلاس InstrPostProcess مربوط به معماری مقصد صورت گیرد. برای نمونه، به متد X86InstrPostProcess::postProcessInstruction در فایل llvm/lib/Target/X86/MCA/X86CustomBehaviour.cpp نگاه کنید.

یک سد بارگذاری/ذخیره‌سازی یک مدخل از صف بارگذاری/ذخیره‌سازی را مصرف می‌کند. یک سد بارگذاری/ذخیره‌سازی رعایت ترتیب بارگذاری‌ها/ذخیره‌سازی‌ها را تحمیل می‌کند. یک بارگذاری جدیدتر نمی‌تواند از یک سد بارگذاری عبور کند. همچنین، یک ذخیره‌سازی جدیدتر نمی‌تواند از یک سد ذخیره‌سازی عبور کند. یک بارگذاری جدیدتر باید تا زمان اجرای سد حافظه/بارگذاری منتظر بماند. یک سد بارگذاری/ذخیره‌سازی زمانی "اجرا می‌شود" که به قدیمی‌ترین مدخل در صف(های) بارگذاری/ذخیره‌سازی تبدیل شود. این موضوع همچنین از نظر ساختاری به این معنی است که تمام بارگذاری‌ها/ذخیره‌سازی‌های قدیمی‌تر اجرا شده‌اند.

در نتیجه، مجموعه کامل قوانین سازگاری بارگذاری/ذخیره‌سازی عبارتند از:

رفتار سفارشی (Custom Behaviour)

به دلیل اینکه برخی از دستورالعمل‌ها به طور کامل درون مدل زمان‌بندی خود بیان نمی‌شوند، llvm-mca همیشه قادر به شبیه‌سازی بی‌نقص آن‌ها نیست. با این حال، اصلاح مدل زمان‌بندی همواره گزینه‌ای عملی نیست (شاید به این دلیل که دستورالعمل عمداً نادرست مدل‌سازی شده است یا رفتار آن بسیار پیچیده است). در این موارد می‌توان از کلاس CustomBehaviour برای اعمال مدل‌سازی صحیح دستورالعمل استفاده کرد (اغلب از طریق سفارشی‌سازی وابستگی‌های داده و شناسایی خطرهایی که llvm-mca هیچ راهی برای اطلاع از آن‌ها ندارد).

ابزار llvm-mca همراه با یک کلاس عمومی و چندین کلاس CustomBehaviour ویژه مقصد ارائه می‌شود. در صورتی که از پرچم -disable-cb استفاده شود یا کلاس CustomBehaviour ویژه آن مقصد وجود نداشته باشد، کلاس عمومی استفاده خواهد شد. (کلاس عمومی هیچ کاری انجام نمی‌دهد.) در حال حاضر، کلاس CustomBehaviour تنها بخشی از خط‌لوله ترتیبی است، اما برنامه‌هایی برای افزودن آن به خط‌لوله خارج از نوبت در آینده وجود دارد.

متد اصلی CustomBehaviour متد checkCustomHazard() است که از دستورالعمل فعلی و فهرستی از تمام دستورالعمل‌هایی که هنوز در خط‌لوله در حال اجرا هستند استفاده می‌کند تا مشخص کند آیا دستورالعمل فعلی باید گسیل شود یا خیر. به عنوان خروجی، این متد یک عدد صحیح را برمی‌گرداند که بیانگر تعداد چرخه‌هایی است که دستورالعمل فعلی باید متوقف شود (اگر عدد دقیق را نمی‌دانید، این مقدار می‌تواند یک برآورد کمتر از واقع باشد، و مقدار 0 نشان‌دهنده عدم توقف است).

اگر مایل به افزودن یک کلاس CustomBehaviour برای مقصدی هستید که قبلاً فاقد آن بوده است، برای مشاهده نحوه راه‌اندازی آن به یکی از پیاده‌سازی‌های موجود مراجعه کنید. این کلاس‌ها در پسانه ویژه مقصد (به عنوان مثال /llvm/lib/Target/AMDGPU/MCA/) پیاده‌سازی می‌شوند تا بتوانند به نمادهای پسانه دسترسی داشته باشند.

مدیر ابزار دقیق (Instrument Manager)

در معماری‌های خاص، اطلاعات زمان‌بندی برای دستورالعمل‌های معین شامل تمامی اطلاعات لازم برای شناسایی دقیق‌ترین کلاس زمان‌بندی نیست. برای نمونه، داده‌هایی که می‌توانند بر زمان‌بندی تأثیر بگذارند ممکن است در ثبات‌های CSR ذخیره شوند.

یک نمونه از این مورد در RISCV است، جایی که مقادیر موجود در ثبات‌هایی نظیر vtype و vl رفتار زمان‌بندی دستورالعمل‌های برداری را تغییر می‌دهند. از آنجا که MCA مقادیر موجود در ثبات‌ها را دنبال نمی‌کند، می‌توان از کامنت‌های ابزار دقیق (instrument comments) برای مشخص کردن این مقادیر استفاده کرد.

تابع اصلی InstrumentManager تابع getSchedClassID() است که به MCInst و تمامی ابزارهای دقیقی که برای آن MCInst فعال هستند دسترسی دارد. این تابع می‌تواند از ابزارها برای بازنویسی کلاس زمان‌بندی MCInst استفاده کند.

در RISCV، کامنت‌های ابزار دقیق حاوی اطلاعات LMUL توسط getSchedClassID() استفاده می‌شوند تا یک دستورالعمل برداری و LMUL فعال را به کلاس زمان‌بندی شبه‌دستورالعملی که آن دستورالعمل پایه و LMUL فعال را توصیف می‌کند نگاشت کنند.

نماهای سفارشی (Custom Views)

ابزار llvm-mca همراه با چندین نما (View) نظیر Timeline View و Summary View ارائه می‌شود. این نماها عمومی هستند و می‌توانند با اکثر (اگر نگوییم همه) مقاصد کار کنند. اگر مایلید یک نمای جدید به llvm-mca اضافه کنید که به هیچ قابلیت پسانه‌ای فراتر از آنچه از قبل از طریق کلاس‌های لایه MC (مانند MCSubtargetInfo، MCInstrInfo و غیره) افشا شده نیاز ندارد، لطفاً آن را به دایرکتوری /tools/llvm-mca/View/ اضافه کنید. با این حال، اگر نمای جدید شما ویژه مقصد است و به نمادها یا قابلیت‌های افشانشده پسانه نیاز دارد، می‌توانید آن را در دایرکتوری /lib/Target/<TargetName>/MCA/ تعریف کنید.

برای فعال‌سازی این نمای ویژه مقصد، باید از کلاس CustomBehaviour مربوط به آن مقصد برای بازنویسی متدهای CustomBehaviour::getViews() استفاده کنید. ۳ گونه از این متدها بر اساس جایی که می‌خواهید نمای شما در خروجی ظاهر شود وجود دارد: getStartViews()، getPostInstrInfoViews() و getEndViews(). این متدها یک بردار از نماها برمی‌گردانند، بنابراین باید برداری حاوی تمام نماهای ویژه مقصد را برای مقصد مورد نظر برگردانید.

از آنجا که این نماهای ویژه مقصد (و وابسته به پسانه) به گونه‌های CustomBehaviour::getViews() نیاز دارند، در صورت استفاده از پرچم -disable-cb فعال نخواهند شد.

فعال کردن این نماهای سفارشی تأثیری بر نماهای غیرسفارشی (عمومی) نمی‌گذارد. برای فعال یا غیرفعال کردن آن نماها همچنان از آرگومان‌های معمولی خط فرمان استفاده کنید..SH "نویسندگان (AUTHORS)" توسط تیم LLVM نگهداری می‌شود (https://llvm.org).