.\" Man page generated from reStructuredText .\" by the Docutils 0.23 manpage writer. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "LLVM-EXEGESIS" "1" "2026-07-15" "22" "LLVM" .SH "نام (NAME)" llvm-exegesis \- سنجش کارایی دستورالعمل‌های ماشین در LLVM .SH "خلاصه دستور (SYNOPSIS)" .sp \fBllvm\-exegesis\fP [\fIoptions\fP] .SH "توضیحات (DESCRIPTION)" .sp \fBllvm\-exegesis\fP ابزاری برای سنجش کارایی (بنچمارک) است که با استفاده از اطلاعات موجود در LLVM، ویژگی‌های دستورالعمل‌های ماشین میزبان مانند تأخیر (latency)، توان عملیاتی (throughput) یا تفکیک پورت (port decomposition) را اندازه‌گیری می‌کند. .sp با دریافت نام یک کد عملیاتی (opcode) در LLVM و یک حالت سنجش کارایی، \fBllvm\-exegesis\fP قطعه‌کدی تولید می‌کند که اجرای آن را تا حد ممکن ترتیبی (به ترتیب، موازی) می‌سازد تا بتوانیم تأخیر (به ترتیب، توان عملیاتی معکوس / تفکیک uop) دستورالعمل را اندازه‌گیری کنیم. این قطعه‌کد به صورت درجا ترجمه (JIT) شده و مگر در صورتی که درخواست عدم اجرای آن داده شده باشد، روی زیرهدف (subtarget) میزبان اجرا می‌شود. زمان صرف‌شده (به ترتیب، میزان مصرف منابع) با استفاده از شمارنده‌های سخت‌افزاری کارایی (performance counters) اندازه‌گیری می‌شود. نتیجه به صورت YAML در خروجی استاندارد چاپ می‌شود. .sp هدف اصلی این ابزار، ارزیابی خودکار اعتبار (تأیید یا رد صحت) مدل‌های زمان‌بندی TableDef در LLVM است. به همین منظور، تحلیلی از نتایج نیز ارائه می‌شود. .sp \fBllvm\-exegesis\fP همچنین می‌تواند قطعه‌کدهای دلخواه ارائه‌شده توسط کاربر را بسنجد. .SH "پلتفرم‌های پشتیبانی‌شده (SUPPORTED PLATFORMS)" .sp \fBllvm\-exegesis\fP در حال حاضر برای سنجش کارایی روی لینوکس فقط از X86 (تنها ۶۴ بیتی)، ARM (تنها AArch64، تولید قطعه‌کد پراکنده است)، MIPS، PowerPC (تنها PowerPC64LE) و RISC\-V (شامل RV64I/E و RV32I/E) پشتیبانی می‌کند. تضمینی وجود ندارد که تمام عملکردهای سنجش روی هر پلتفرمی کار کنند. \fBllvm\-exegesis\fP همچنین دارای یک حالت تحلیل مجزا است که روی تمام پلتفرم‌های پشتیبانی‌شده توسط LLVM کار می‌کند. .sp برای فعال‌سازی سنجش کارایی در llvm\-exegesis، باید LLVM را با فعال بودن \fILLVM_ENABLE_LIBPFM\fP پیکربندی و کامپایل کرد، زیرا \fBllvm\-exegesis\fP برای دسترسی به شمارنده‌های کارایی به libpfm4 وابسته است. اگر پردازندهٔ هدف توسط libpfm پشتیبانی نشود، ممکن است سنجش شکست بخورد. این موضوع را می‌توان با مقداردهی متغیرهای محیطی \fILIBPFM_VERBOSE\fP و \fILIBPFM_DEBUG\fP جهت فعال‌سازی حالت پرحرف (verbose) یا اشکال‌زدایی (debug) برای libpfm بررسی کرد. اگر libpfm در دایرکتوری غیراستانداردی نصب شده باشد، می‌توان LLVM را برای یافتن فایل‌های سرآیند و کتابخانهٔ لازم با مقداردهی متغیرهای محیطی \fILIBRARY_PATH\fP، \fIC_INCLUDE_PATH\fP و \fICPLUS_INCLUDE_PATH\fP پیکربندی کرد. علاوه بر این، \fILD_LIBRARY_PATH\fP باید تنظیم شود تا \fBllvm\-exegesis\fP بتواند کتابخانهٔ libpfm را در زمان اجرا پیدا کند. .SH "حاشیه‌نویسی‌های قطعه‌کد (SNIPPET ANNOTATIONS)" .sp \fBllvm\-exegesis\fP از سنجش کارایی قطعه‌کدهای اسمبلی دلخواه پشتیبانی می‌کند. با این حال، سنجش این قطعه‌کدها اغلب نیازمند پیکربندی و راه‌اندازی اولیه است تا بتوانند به درستی اجرا شوند. \fBllvm\-exegesis\fP دارای پنج حاشیه‌نویسی (annotation) و ابزارهای کمکی دیگری است که به راه‌اندازی اولیه جهت سنجش صحیح قطعه‌کدها کمک می‌کنند. .INDENT 0.0 .IP \(bu 2 \fILLVM\-EXEGESIS\-DEFREG \fP \- افزودن این حاشیه‌نویسی به قطعه‌کد متنی اسمبلی جهت بنچمارک، ثبات (register) را به عنوان نیازمند مقداردهی مشخص می‌کند. مقداری به طور خودکار فراهم خواهد شد، مگر اینکه پارامتر دومی به صورت یک مقدار هگزادسیمال (hex) وارد شود. این کار با ساختار \fILLVM\-EXEGESIS\-DEFREG \fP انجام می‌گیرد. \fI\fP یک الگوی بیتی است که برای پر کردن ثبات استفاده می‌شود. اگر این مقدار از اندازهٔ ثبات کوچک‌تر باشد، با حفظ علامت (sign extended) گسترش می‌یابد تا با اندازهٔ ثبات مطابقت پیدا کند. .IP \(bu 2 \fILLVM\-EXEGESIS\-LIVEIN \fP \- این حاشیه‌نویسی امکان تعیین ثبات‌هایی را فراهم می‌کند که باید مقدار خود را در هنگام شروع بنچمارک حفظ کنند. در برخی موارد مقادیر می‌توانند از طریق ثبات‌ها از بخش راه‌اندازی بنچمارک منتقل شوند. ثبات‌ها و مقادیر تخصیص‌یافته به آن‌ها که می‌توانند در اسکریپت بنچمارک با \fILLVM\-EXEGESIS\-LIVEIN\fP استفاده شوند، به شرح زیر هستند: .INDENT 2.0 .IP \(bu 2 ثبات حافظهٔ موقت (Scratch memory register) \- ثبات خاصی که این مقدار در آن قرار می‌گیرد وابسته به پلتفرم است (برای نمونه، در X86 Linux ثبات RDI است). تنظیم این ثبات به عنوان live in تضمین می‌کند که اشاره‌گری به یک بلوک حافظه (۱ مگابایت) در این ثبات قرار می‌گیرد که می‌تواند توسط قطعه‌کد استفاده شود. .UNINDENT .IP \(bu 2 \fILLVM\-EXEGESIS\-MEM\-DEF \fP \- این حاشیه‌نویسی امکان تعیین تعاریف حافظه‌ای را فراهم می‌کند که می‌توانند بعداً با حاشیه‌نویسی \fILLVM\-EXEGESIS\-MEM\-MAP\fP به فرآیند اجرای قطعه‌کد نگاشت (map) شوند. هر مقدار با استفاده از آرگومان \fI\fP نام‌گذاری می‌شود تا بتوان بعداً درون یک حاشیه‌نویسی نگاشت به آن ارجاع داد. اندازه به صورت تعداد بایت‌ها در مبنای ۱۰ (اعشاری) مشخص شده و مقدار در مبنای ۱۶ (هگزادسیمال) ارائه می‌شود. اگر اندازهٔ مقدار کمتر از اندازهٔ مشخص‌شده باشد، مقدار تا زمانی تکرار می‌شود که کل بخش حافظه را پر کند. استفاده از این حاشیه‌نویسی نیازمند استفاده از حالت اجرای زیرفرآیند (subprocess execution mode) است. .IP \(bu 2 \fILLVM\-EXEGESIS\-MEM\-MAP
\fP \- این حاشیه‌نویسی امکان نگاشت تعاریف حافظهٔ از پیش تعریف‌شده را به بافتار اجرای (execution context) یک فرآیند فراهم می‌کند. نام مقدار به یک تعریف حافظهٔ از پیش تعیین‌شده اشاره دارد و آدرس، عددی در مبنای ۱۰ است که آدرس شروع تعریف حافظه را مشخص می‌کند. توجه داشته باشید که یک تعریف حافظه می‌تواند چندین بار نگاشت شود. استفاده از این حاشیه‌نویسی نیازمند حالت اجرای زیرفرآیند است. .IP \(bu 2 \fILLVM\-EXEGESIS\-SNIPPET\-ADDRESS
\fP \- این حاشیه‌نویسی امکان تعیین آدرسی را فراهم می‌کند که ابتدای قطعه‌کد برای اجرا در آنجا نگاشت خواهد شد. آدرس در مبنای ۱۶ (هگزادسیمال) داده می‌شود. توجه داشته باشید که قطعه‌کد شامل کد راه‌اندازی اولیه نیز می‌باشد، بنابراین دستورالعمل دقیقاً واقع در آدرس مشخص‌شده، اولین دستورالعمل درون قطعه‌کد نخواهد بود. استفاده از این حاشیه‌نویسی نیازمند حالت اجرای زیرفرآیند است. این ویژگی در مواردی کاربرد دارد که حافظهٔ مورد دسترسی قطعه‌کد به مکان قطعه‌کد وابسته است؛ مانند آدرس‌دهی وابسته به RIP (RIP\-relative addressing). .IP \(bu 2 \fILLVM\-EXEGESIS\-LOOP\-REGISTER \fP \- این حاشیه‌نویسی، ثبات حلقه را برای ردیابی تکرار فعلی در هنگام استفاده از حالت تکرار حلقه (loop repetition mode) مشخص می‌کند. \fBllvm\-exegesis\fP باید تکرار فعلی حلقه را درون حالت تکرار حلقه به شیوه‌ای با کارایی بالا (یعنی بدون دسترسی به حافظه) دنبال کند و برای این کار از یک ثبات استفاده می‌کند. این ثبات یک مقدار پیش‌فرض مختص معماری دارد (مانند \fIR8\fP در X86)، اما این ممکن است با برخی از قطعه‌کدها تداخل داشته باشد. این حاشیه‌نویسی امکان تغییر ثبات را فراهم می‌کند تا از تداخل بین ثبات شاخص حلقه و قطعه‌کد جلوگیری شود. .UNINDENT.SH "مثال ۱: بنچمارک دستورالعمل‌ها (EXAMPLE 1: BENCHMARKING INSTRUCTIONS)" .sp فرض کنید یک دستگاه X86\-64 دارید. برای اندازه‌گیری تاخیر (latency) یک تک‌دستورالعمل، اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ llvm\-exegesis \-\-mode=latency \-\-opcode\-name=ADD64rr .EE .UNINDENT .UNINDENT .sp اندازه‌گیری تجزیه uop یا توان عملیاتی معکوس (inverse throughput) یک دستورالعمل نیز به روشی مشابه کار می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX $ llvm\-exegesis \-\-mode=uops \-\-opcode\-name=ADD64rr $ llvm\-exegesis \-\-mode=inverse_throughput \-\-opcode\-name=ADD64rr .EE .UNINDENT .UNINDENT .sp خروجی یک سند YAML است (حالت پیش‌فرض نوشتن در stdout است، اما می‌توانید با استفاده از \fI\-\-benchmarks\-file\fP خروجی را به یک فایل هدایت کنید): .INDENT 0.0 .INDENT 3.5 .sp .EX \-\-\- key: opcode_name: ADD64rr mode: latency config: \(aq\(aq cpu_name: haswell llvm_triple: x86_64\-unknown\-linux\-gnu num_repetitions: 10000 measurements: \- { key: latency, value: 1.0058, debug_string: \(aq\(aq } error: \(aq\(aq info: \(aqexplicit self cycles, selecting one aliasing configuration. Snippet: ADD64rr R8, R8, R10 \(aq \&... .EE .UNINDENT .UNINDENT .sp برای اندازه‌گیری تاخیر تمامی دستورالعمل‌ها برای معماری میزبان، اجرا کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ llvm\-exegesis \-\-mode=latency \-\-opcode\-index=\-1 .EE .UNINDENT .UNINDENT .SH "مثال ۲: بنچمارک یک قطعه‌کد سفارشی (EXAMPLE 2: BENCHMARKING A CUSTOM CODE SNIPPET)" .sp برای اندازه‌گیری تاخیر/uops یک قطعه‌کد سفارشی، می‌توانید گزینهٔ \fIsnippets\-file\fP را مشخص کنید (\fI\-\fP از ورودی استاندارد می‌خواند). .INDENT 0.0 .INDENT 3.5 .sp .EX $ echo \(dqvzeroupper\(dq | llvm\-exegesis \-\-mode=uops \-\-snippets\-file=\- .EE .UNINDENT .UNINDENT .sp قطعه‌کدهای دنیای واقعی معمولاً به ثبات‌ها یا حافظه وابسته هستند. \fBllvm\-exegesis\fP سرزندگی (liveliness) ثبات‌ها را بررسی می‌کند (یعنی هر استفاده از یک ثبات دارای یک تعریف (def) متناظر است یا به‌صورت \(dqlive in\(dq می‌باشد). اگر کد شما به مقدار برخی از ثبات‌ها وابسته است، باید از نشانه‌گذاری‌های قطعه‌کد (snippet annotations) استفاده کنید تا مطمئن شوید که مقداردهی اولیه به درستی انجام می‌شود. .sp برای مثال، قطعه‌کد زیر به مقادیر XMM1 (که توسط ابزار مقداردهی خواهد شد) و بافر حافظه ارسال‌شده در RDI (به‌صورت live in) وابسته است. .INDENT 0.0 .INDENT 3.5 .sp .EX # LLVM\-EXEGESIS\-LIVEIN RDI # LLVM\-EXEGESIS\-DEFREG XMM1 42 vmulps (%rdi), %xmm1, %xmm2 vhaddps %xmm2, %xmm2, %xmm3 addq $0x10, %rdi .EE .UNINDENT .UNINDENT.SH "مثال ۳: محک‌زنی با حاشیه‌نویسی‌های حافظه (EXAMPLE 3: BENCHMARKING WITH MEMORY ANNOTATIONS)" .sp برخی از قطعه‌کدها برای اجرا بدون از کار افتادگی (crash)، نیازمند برپاسازی حافظه در مکان‌های خاصی هستند. برپاسازی حافظه را می‌توان با استفاده از حاشیه‌نویسی‌های \fILLVM\-EXEGESIS\-MEM\-DEF\fP و \fILLVM\-EXEGESIS\-MEM\-MAP\fP انجام داد. برای اجرای قطعه‌کد زیر: .INDENT 0.0 .INDENT 3.5 .sp .EX movq $8192, %rax movq (%rax), %rdi .EE .UNINDENT .UNINDENT .sp باید حداقل هشت بایت حافظهٔ تخصیص‌یافته با شروع از \fI0x2000\fP\& داشته باشیم. ما می‌توانیم محیط اجرای لازم را با افزودن حاشیه‌نویسی‌های زیر به قطعه‌کد ایجاد کنیم: .INDENT 0.0 .INDENT 3.5 .sp .EX # LLVM\-EXEGESIS\-MEM\-DEF test1 4096 7fffffff # LLVM\-EXEGESIS\-MEM\-MAP test1 8192 movq $8192, %rax movq (%rax), %rdi .EE .UNINDENT .UNINDENT .SH "مثال ۴: تحلیل (EXAMPLE 4: ANALYSIS)" .sp با فرض اینکه مجموعه‌ای از دستورالعمل‌های محک‌زده‌شده (چه latency و چه uops) را در قالب YAML در فایل \fI/tmp/benchmarks.yaml\fP دارید، می‌توانید نتایج را با استفاده از دستور زیر تحلیل کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX $ llvm\-exegesis \-\-mode=analysis \e \-\-benchmarks\-file=/tmp/benchmarks.yaml \e \-\-analysis\-clusters\-output\-file=/tmp/clusters.csv \e \-\-analysis\-inconsistencies\-output\-file=/tmp/inconsistencies.html .EE .UNINDENT .UNINDENT .sp این کار دستورالعمل‌ها را در خوشه‌هایی با ویژگی‌های عملکردی یکسان گروه‌بندی می‌کند. خوشه‌ها با قالب زیر در \fI/tmp/clusters.csv\fP نوشته خواهند شد: .INDENT 0.0 .INDENT 3.5 .sp .EX cluster_id,opcode_name,config,sched_class \&... 2,ADD32ri8_DB,,WriteALU,1.00 2,ADD32ri_DB,,WriteALU,1.01 2,ADD32rr,,WriteALU,1.01 2,ADD32rr_DB,,WriteALU,1.00 2,ADD32rr_REV,,WriteALU,1.00 2,ADD64i32,,WriteALU,1.01 2,ADD64ri32,,WriteALU,1.01 2,MOVSX64rr32,,BSWAP32r_BSWAP64r_MOVSX64rr32,1.00 2,VPADDQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.02 2,VPSUBQYrr,,VPADDBYrr_VPADDDYrr_VPADDQYrr_VPADDWYrr_VPSUBBYrr_VPSUBDYrr_VPSUBQYrr_VPSUBWYrr,1.01 2,ADD64ri8,,WriteALU,1.00 2,SETBr,,WriteSETCC,1.01 \&... .EE .UNINDENT .UNINDENT .sp ابزار \fBllvm\-exegesis\fP همچنین خوشه‌ها را برای مشخص کردن ناسازگاری‌ها در اطلاعات زمان‌بندی (scheduling) تحلیل خواهد کرد. خروجی یک فایل html است. برای نمونه، \fI/tmp/inconsistencies.html\fP شامل پیام‌هایی مانند مورد زیر خواهد بود: [تصویر] .sp توجه داشته باشید که نام‌های کلاس زمان‌بندی تنها زمانی مشخص خواهند شد که \fBllvm\-exegesis\fP در حالت اشکال‌زدایی (debug) کامپایل شده باشد؛ در غیر این صورت، تنها شناسه کلاس (class id) نمایش داده می‌شود. با این حال، این موضوع هیچ‌یک از نتایج تحلیل را بی‌اعتبار نمی‌کند..SH "گزینه‌ها (OPTIONS)" .INDENT 0.0 .TP .B \-\-help چاپ خلاصه‌ای از گزینه‌های خط فرمان. .UNINDENT .INDENT 0.0 .TP .B \-\-opcode\-index= مشخص کردن opcode برای اندازه‌گیری، بر اساس اندیس. مشخص کردن \fI\-1\fP منجر به اندازه‌گیری تمام opcodeهای موجود خواهد شد. برای جزئیات به مثال ۱ مراجعه کنید. باید یکی از گزینه‌های \fIopcode\-index\fP، \fIopcode\-name\fP یا \fIsnippets\-file\fP تعیین شده باشد. .UNINDENT .INDENT 0.0 .TP .B \-\-opcode\-name=,,... مشخص کردن opcode برای اندازه‌گیری، بر اساس نام. چندین opcode را می‌توان به صورت فهرستی جداشده با کاما تعیین کرد. برای جزئیات به مثال ۱ مراجعه کنید. باید یکی از گزینه‌های \fIopcode\-index\fP، \fIopcode\-name\fP یا \fIsnippets\-file\fP تعیین شده باشد. .UNINDENT .INDENT 0.0 .TP .B \-\-snippets\-file= مشخص کردن قطعه‌کد سفارشی برای اندازه‌گیری. برای جزئیات به مثال ۲ مراجعه کنید. باید یکی از گزینه‌های \fIopcode\-index\fP، \fIopcode\-name\fP یا \fIsnippets\-file\fP تعیین شده باشد. .UNINDENT .INDENT 0.0 .TP .B \-\-mode=[latency|uops|inverse_throughput|analysis] مشخص کردن حالت اجرا. توجه داشته باشید که برخی حالت‌ها نیازمندی‌ها و گزینه‌های اضافی دارند. .sp حالت \fIlatency\fP می‌تواند از RDTSC یا LBR استفاده کند. حالت \fIlatency[LBR]\fP تنها در X86 (حداقل \fISkylake\fP) در دسترس است. برای اجرا در حالت \fIlatency\fP، باید مقداری مثبت برای \fIx86\-lbr\-sample\-period\fP و همچنین \fI\-\-repetition\-mode=loop\fP\& تعیین شود. .sp در حالت \fIanalysis\fP، شما همچنین باید حداقل یکی از گزینه‌های \fI\-analysis\-clusters\-output\-file=\fP یا \fI\-analysis\-inconsistencies\-output\-file=\fP\& را مشخص کنید. .UNINDENT .INDENT 0.0 .TP .B \-\-benchmark\-phase=[prepare\-snippet|prepare\-and\-assemble\-snippet|assemble\-measured\-code|measure] به طور پیش‌فرض، هنگامی که \fI\-mode=\fP مشخص می‌شود، قطعه‌کد تولیدشده اجرا و اندازه‌گیری خواهد شد؛ این امر مستلزم آن است که برنامه روی سخت‌افزاری اجرا شود که قطعه‌کد برای آن تولید شده و از اندازه‌گیری‌های کارایی پشتیبانی می‌کند. با این حال، امکان متوقف کردن فرآیند در مراحلی پیش از اندازه‌گیری وجود دارد. گزینه‌ها عبارتند از: * \fBprepare\-snippet\fP: تنها توالی کمینه دستورالعمل‌ها را تولید می‌کند. * \fBprepare\-and\-assemble\-snippet\fP: مانند \fBprepare\-snippet\fP، اما همچنین بخشی از توالی را به صورت هگزادسیمال (hex encoded) استخراج می‌کند. * \fBassemble\-measured\-code\fP: مانند \fBprepare\-and\-assemble\-snippet\fP\&، اما کل توالی را ایجاد می‌کند که می‌تواند با استفاده از \fB\-\-dump\-object\-to\-disk\fP\& در یک فایل ذخیره شود. * \fBmeasure\fP: مانند \fBassemble\-measured\-code\fP، اما اندازه‌گیری را نیز اجرا می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-\-x86\-lbr\-sample\-period= دوره نمونه‌برداری LBR را مشخص می‌کند \- یعنی چند انشعاب پیش از گرفتن نمونه طی شود. هنگامی که مقداری مثبت برای این گزینه تعیین شود و حالت برابر با \fIlatency\fP باشد، از LBRها برای اندازه‌گیری استفاده خواهد شد. در انتخاب دوره نمونه‌برداری \(dqمناسب\(dq، مقادیر کوچک‌تر ترجیح داده می‌شوند، اما در صورت تکرار بیش از حد نمونه‌برداری، ممکن است گلوگاه و افت نرخ نمونه‌برداری (throttling) رخ دهد. توصیه می‌شود از یک عدد اول استفاده شود تا از نادیده گرفته شدن مداوم برخی بلوک‌های خاص جلوگیری گردد. .UNINDENT .INDENT 0.0 .TP .B \-\-x86\-disable\-upper\-sse\-registers استفاده از ثبات‌های بالایی xmm (شامل xmm8\-xmm15) باعث طولانی‌تر شدن کدگذاری دستورالعمل‌ها می‌شود که ممکن است فشار بیشتری به مراحل واکشی (fetch) و رمزگشایی (decode) در بخش frontend وارد کند؛ این موضوع به ویژه در سخت‌افزارهای قدیمی‌تر، پتانسیل کاهش نرخ اعزام (dispatch) دستورالعمل‌ها به backend را دارد. مقایسه نتایج پایه با فعال بودن این حالت می‌تواند به تعیین اثرات frontend کمک کرده و برای بهبود تخمین‌های تاخیر (latency) و توان عملیاتی (throughput) استفاده شود. .UNINDENT .INDENT 0.0 .TP .B \-\-repetition\-mode=[duplicate|loop|min|middle\-half\-duplicate|middle\-half\-loop] مشخص کردن حالت تکرار. گزینه \fIduplicate\fP یک بلوک پایه (basic block) بزرگ و خطی با \fImin\-instructions\fP دستورالعمل ایجاد می‌کند (تکرار قطعه‌کد به تعداد \fImin\-instructions\fP/\fIsnippet size\fP مرتبه). گزینه \fIloop\fP در صورت لزوم، قطعه‌کد را تا زمانی تکرار می‌کند که بدنه حلقه حداقل شامل \fIloop\-body\-size\fP دستورالعمل باشد، و سپس نتیجه را درون حلقه‌ای قرار می‌دهد که \fImin\-instructions\fP دستورالعمل را اجرا خواهد کرد (بنابراین مجدداً قطعه‌کد را \fImin\-instructions\fP/\fIsnippet size\fP بار تکرار می‌کند). حالت \fIloop\fP، به ویژه همراه با باز کردن حلقه (loop unrolling)، تمایل دارد اثرات frontend پردازنده را در معماری‌هایی که دستورالعمل‌های رمزگشایی‌شده را حافظه پنهان می‌کنند بهتر پنهان سازد، اما یک ثبات را برای شمارش تکرارها مصرف می‌کند. اگر در حال انجام تحلیل روی چندین opcode هستید، شاید بهتر باشد از حالت \fImin\fP استفاده کنید که هر یک از حالت‌های دیگر را اجرا کرده و کمترین نتیجه اندازه‌گیری‌شده را برمی‌گرداند. حالت‌های تکرار middle half بسته به حالت خاص، قطعه‌کد را تکرار کرده یا درون حلقه اجرا می‌کنند. این حالت‌ها دو بنچمارک اجرا می‌کنند، یکی با دو برابر طول اولی، و سپس تفاضل میان آن‌ها را برای به دست آوردن مقادیر بدون سربار (overhead) کسر می‌کنند. .UNINDENT .INDENT 0.0 .TP .B \-\-min\-instructions= تعداد هدف برای دستورالعمل‌های اجراشده را مشخص می‌کند. توجه داشته باشید که تعداد تکرار واقعی قطعه‌کد برابر با \fImin\-instructions\fP/\fIsnippet size\fP\& خواهد بود. مقادیر بالاتر منجر به اندازه‌گیری‌های دقیق‌تر می‌شوند اما زمان اجرای بنچمارک را طولانی‌تر می‌کنند. .UNINDENT .INDENT 0.0 .TP .B \-\-loop\-body\-size= تنها برای \fI\-repetition\-mode=[loop|min]\fP\& مؤثر است. به جای اجرای مستقیم حلقه روی قطعه‌کد، ابتدا آن را کپی می‌کند تا بدنه حلقه حداقل شامل این تعداد دستورالعمل باشد. این امر به صورت بالقوه منجر به قرارگیری بدنه حلقه در حافظه پنهان دستورات پردازنده (Op Cache / Loop Cache) می‌شود که ممکن است توان عملیاتی بالاتری نسبت به رمزگشاهای پردازنده داشته باشد. .UNINDENT .INDENT 0.0 .TP .B \-\-max\-configs\-per\-opcode= حداکثر پیکربندی‌هایی که می‌توان برای هر opcode تولید کرد را مشخص می‌کند. به طور پیش‌فرض این مقدار \fI1\fP است، به این معنی که فرض می‌کنیم یک اندازه‌گیری واحد برای توصیف ویژگی‌های یک opcode کافی است. ممکن است این مورد برای همه دستورالعمل‌ها صادق نباشد؛ برای مثال، مشخصات کارایی دستورالعمل LEA در X86 به مقدار ثبات‌ها و مقادیر بی‌درنگ (immediates) تخصیص‌یافته بستگی دارد. تعیین مقداری بزرگتر از \fI1\fP برای \fI\-max\-configs\-per\-opcode\fP به \fIllvm\-exegesis\fP اجازه می‌دهد تا پیکربندی‌های بیشتری را بررسی کند تا مشخص شود آیا برخی از انتساب‌های ثبات یا مقدار بی‌درنگ منجر به ویژگی‌های کارایی متفاوتی می‌شوند یا خیر. .UNINDENT .INDENT 0.0 .TP .B \-\-benchmarks\-file= فایلی برای خواندن (حالت \fIanalysis\fP) یا نوشتن (حالت‌های \fIlatency\fP/\fIuops\fP/\fIinverse_throughput\fP) نتایج بنچمارک. مقدار \(dq\-\(dq از stdin/stdout استفاده می‌کند. .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-clusters\-output\-file= در صورت ارائه، خوشه‌های تحلیل را با ساختار CSV در این فایل می‌نویسد. مقدار \(dq\-\(dq خروجی را در stdout چاپ می‌کند. به طور پیش‌فرض، این تحلیل اجرا نمی‌شود. .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-inconsistencies\-output\-file= در صورت غیرخالی بودن، ناسازگاری‌های یافت‌شده در طول تحلیل را در این فایل می‌نویسد. مقدار \fI\-\fP خروجی را در stdout چاپ می‌کند. به طور پیش‌فرض، این تحلیل اجرا نمی‌شود. .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-filter=[all|reg\-only|mem\-only] به طور پیش‌فرض، همه نتایج بنچمارک تحلیل می‌شوند، اما گاهی اوقات ممکن است بررسی مواردی که حافظه را درگیر نمی‌کنند مفید باشد، یا برعکس. این گزینه اجازه می‌دهد تا یا همه بنچمارک‌ها حفظ شوند، یا تمام مواردی که حافظه را درگیر می‌کنند (شامل دستورالعمل‌هایی که ممکن است از حافظه بخوانند یا در آن بنویسند) نادیده گرفته شوند، یا برعکس، فقط چنین بنچمارک‌هایی نگه داشته شوند. .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-clustering=[dbscan,naive] الگوریتم خوشه‌بندی مورد استفاده را مشخص می‌کند. به طور پیش‌فرض DBSCAN استفاده خواهد شد. الگوریتم خوشه‌بندی Naive برای پردازش‌های بیشتر روی خروجی \fI\-analysis\-inconsistencies\-output\-file=\fP مناسب‌تر است؛ این الگوریتم به ازای هر opcode یک خوشه ایجاد کرده و پایدار بودن آن خوشه را بررسی می‌کند (اینکه آیا همه نقاط همسایه یکدیگرند یا خیر). .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-numpoints= پارامتر numPoints مورد استفاده در خوشه‌بندی DBSCAN را مشخص می‌کند (حالت \fIanalysis\fP، فقط DBSCAN). .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-clustering\-epsilon= پارامتر epsilon مورد استفاده برای خوشه‌بندی نقاط بنچمارک را مشخص می‌کند (حالت \fIanalysis\fP). .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-inconsistency\-epsilon= پارامتر epsilon مورد استفاده برای تشخیص زمان تفاوت خوشه با مقادیر پروفایل زمان‌بندی LLVM را مشخص می‌کند (حالت \fIanalysis\fP). .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-display\-unstable\-clusters اگر بیش از یک بنچمارک برای یک opcode وجود داشته باشد، در صورتی که ویژگی‌های کارایی اندازه‌گیری‌شده متفاوت باشند ممکن است این بنچمارک‌ها در یک خوشه یکسان قرار نگیرند. به طور پیش‌فرض همه این opcodeها فیلتر می‌شوند. این پرچم در عوض، تنها چنین opcodeهای ناپایداری را نمایش می‌دهد. .UNINDENT .INDENT 0.0.TP .B \-\-ignore\-invalid\-sched\-class=false در صورت تنظیم، دستورالعمل‌هایی که فاقد کلاس زمان‌بندی (sched class) هستند (class idx = 0) نادیده گرفته می‌شوند. .UNINDENT .INDENT 0.0 .TP .B \-\-mtriple= سه‌گانهٔ هدف (Target triple). برای دیدن هدف‌های موجود، \fI\-version\fP را ببینید. .UNINDENT .INDENT 0.0 .TP .B \-\-mcpu= در صورت تنظیم، ویژگی‌های پردازنده با استفاده از شمارنده‌های این پردازنده اندازه‌گیری می‌شود. این گزینه هنگام ایجاد مدل‌های زمان‌بندی جدید (زمانی که پردازندهٔ میزبان برای LLVM ناشناخته است) مفید است. (برای جزئیات \fI\-mcpu=help\fP را ببینید) .UNINDENT .INDENT 0.0 .TP .B \-\-analysis\-override\-benchmark\-triple\-and\-cpu به‌طور پیش‌فرض، llvm\-exegesis محک‌ها (benchmarks) را برای سه‌گانه/پردازنده‌ای که رویش اندازه‌گیری شده‌اند تحلیل می‌کند، اما اگر بخواهید آن‌ها را برای ترکیب دیگری تحلیل کنید (که از طریق \fI\-mtriple\fP/\fI\-mcpu\fP مشخص می‌شود)، می‌توانید این پرچم را مشخص کنید. .UNINDENT .INDENT 0.0 .TP .B \-\-dump\-object\-to\-disk= در صورت تنظیم، llvm\-exegesis کد تولیدشده را برای امکان بازبینی کد درون یک فایل موقت ذخیره می‌کند. به‌طور پیش‌فرض غیرفعال است. .UNINDENT .INDENT 0.0 .TP .B \-\-use\-dummy\-perf\-counters در صورت تنظیم، llvm\-exegesis هیچ شمارندهٔ کارایی واقعی را نمی‌خواند و در عوض یک مقدار ساختگی بازمی‌گرداند. این گزینه می‌تواند برای اطمینان از فروپاشی نکردن قطعه‌کد (snippet) در زمان عدم دسترسی به شمارنده‌های کارایی سخت‌افزاری و همچنین برای اشکال‌زدایی خود \fBllvm\-exegesis\fP استفاده شود. .UNINDENT .INDENT 0.0 .TP .B \-\-execution\-mode=[inprocess,subprocess] این گزینه حالت اجرایی مورد استفاده را مشخص می‌کند. حالت اجرای \fIinprocess\fP پیش‌فرض است. حالت اجرای \fIsubprocess\fP امکانات بیشتری مانند یادداشت‌های حافظه (memory annotations) را فراهم می‌کند، اما در حال حاضر به X86\-64 روی لینوکس محدود است. .UNINDENT .INDENT 0.0 .TP .B \-\-benchmark\-repeat\-count= این گزینه امکان تعیین تعداد دفعات تکرار اندازه‌گیری را هنگام انجام اندازه‌گیری‌های تاخیر (latency) فراهم می‌کند. به‌طور پیش‌فرض، llvm\-exegesis یک اندازه‌گیری تاخیر را به تعداد دفعات کافی تکرار می‌کند تا تعادلی بین زمان اجرا و کاهش نویز برقرار شود. .UNINDENT .INDENT 0.0 .TP .B \-\-validation\-counter=[instructions\-retired,l1d\-cache\-load\-misses, .TP .B l1d\-cache\-store\-misses,l1i\-cache\-load\-misses,data\-tlb\-load\-misses, .TP .B data\-tld\-store\-misses,instruction\-tlb\-load\-misses] این گزینه استفاده از شمارنده‌های اعتبارسنجی را فعال می‌کند؛ این شمارنده‌ها رخدادهای ریزمعماری اضافی مانند خطاهای حافظهٔ نهان (cache misses) را برای اعتبارسنجی شرایط اجرای قطعه‌کد اندازه‌گیری می‌کنند. این رخدادها با استفاده از زیرسیستم perf و در یک گروه مشترک با شمارندهٔ کاراییِ مورد استفاده برای اندازه‌گیری مقدار مورد نظر، سنجیده می‌شوند. این پرچم را می‌توان چندین بار برای اندازه‌گیری چندین رخداد مشخص کرد. حداکثر تعداد شمارنده‌های اعتبارسنجی به پلتفرم بستگی دارد. .UNINDENT .INDENT 0.0 .TP .B \-\-benchmark\-process\-cpu= این گزینه شمارهٔ پردازنده‌ای را مشخص می‌کند که باید برای اجرای زیرپردازهٔ محک‌زنی استفاده شود. هنگام شروع زیرپردازه، \fBllvm\-exegesis\fP همبستگی پردازشی (affinity) زیرپردازه را طوری تنظیم می‌کند که تنها شامل پردازندهٔ مشخص‌شده باشد. این گزینه فقط در حالت اجرای subprocess کار می‌کند. .UNINDENT .SH "وضعیت خروج (EXIT STATUS)" .sp \fBllvm\-exegesis\fP در صورت موفقیت 0 بازمی‌گرداند. در غیر این صورت، یک پیام خطا در خروجی استاندارد خطا چاپ می‌شود و این ابزار مقداری غیر از 0 را برمی‌گرداند. .SH "نویسندگان (AUTHORS)" توسط تیم LLVM نگهداری می‌شود (https://llvm.org)..SH "کپی‌رایت و تکثیر (COPYRIGHT)" 2003-2026, LLVM Project .\" End of generated man page.