[llvm] [BOLT][Linux] Optionally only handle C functions (PR #130478)

[via llvm-commits]

https://github.com/FLZ101 created https://github.com/llvm/llvm-project/pull/130478

BOLT can not handle some functions defined in assembly code reliably, since they may have extra semantics/enforcements BOLT can never know. For example, irq_entries_start defined in arch/x86/include/asm/idtentry.h is actually an “array” but BOLT views it as an ordinary function. If BOLT applies basic block reordering, instrumentation, etc to it, run time errors would happen.

We could explicitly specify those functions to skip, but to find all of them we usually need to test & debug many times. That is a lot of work and we may still miss some.

In my own experience, when adapting BOLT for Linux to a new architecture or Linux version, we may spend lots of time on fixing runtime errors related to functions defined in assembly code.

Only handling C functions makes BOLT for Linux more reliable, and may save lots of development efforts.

It can be used as follows:

* put "-mllvm -bolt-function-list-file=filename" in KCFLAGS when buildling Linux
* specify "-funcs-file-no-regex=filename" when invoking llvm-bolt

>From 6b8d5d9e9d0a0686cb4ac5ce55f58e100e91104a Mon Sep 17 00:00:00 2001
From: Franklin <zhangfenglei at huawei.com>
Date: Sun, 9 Mar 2025 18:06:10 +0800
Subject: [PATCH] [BOLT][Linux] Optionally only handle C functions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

BOLT can not handle some functions defined in assembly code reliably, since
they may have extra semantics/enforcements BOLT can never know. For example,
irq_entries_start defined in arch/x86/include/asm/idtentry.h is actually an
“array” but BOLT views it as an ordinary function. If BOLT applies basic
block reordering, instrumentation, etc to it, run time errors would happen.

We could explicitly specify those functions to skip, but to find all of them
we usually need to test & debug many times. That is a lot of work and we may
still miss some.

In my own experience, when adapting BOLT for Linux to a new architecture or
Linux version, we may spend lots of time on fixing runtime errors related to
functions defined in assembly code.

Only handling C functions makes BOLT for Linux more reliable, and may save
lots of development efforts.

It can be used as follows:

* put "-mllvm -bolt-function-list-file=filename" in KCFLAGS when
  buildling Linux
* specify "-funcs-file-no-regex=filename" when invoking llvm-bolt
---
 llvm/lib/CodeGen/CodeGenPrepare.cpp | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/llvm/lib/CodeGen/CodeGenPrepare.cpp b/llvm/lib/CodeGen/CodeGenPrepare.cpp
index 088062afab177..6fd6cc9983bbb 100644
--- a/llvm/lib/CodeGen/CodeGenPrepare.cpp
+++ b/llvm/lib/CodeGen/CodeGenPrepare.cpp
@@ -85,6 +85,7 @@
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
@@ -274,6 +275,10 @@ static cl::opt<bool>
     DisableDeletePHIs("disable-cgp-delete-phis", cl::Hidden, cl::init(false),
                       cl::desc("Disable elimination of dead PHI nodes."));
 
+cl::opt<std::string>
+    BoltFunctionListFile("bolt-function-list-file", cl::Hidden,
+                         cl::desc("Specify BOLT function list file"));
+
 namespace {
 
 enum ExtType {
@@ -506,6 +511,14 @@ class CodeGenPrepareLegacyPass : public FunctionPass {
 char CodeGenPrepareLegacyPass::ID = 0;
 
 bool CodeGenPrepareLegacyPass::runOnFunction(Function &F) {
+  if (!BoltFunctionListFile.empty()) {
+    std::error_code EC;
+    raw_fd_ostream OS(BoltFunctionListFile, EC, sys::fs::OpenFlags::OF_Append);
+    if (EC)
+      report_fatal_error(Twine(BoltFunctionListFile) + ": " + EC.message());
+    OS << F.getName() << "\n";
+  }
+
   if (skipFunction(F))
     return false;
   auto TM = &getAnalysis<TargetPassConfig>().getTM<TargetMachine>();