diff --git a/docs/zh/server/_toc.yaml b/docs/zh/server/_toc.yaml
index 09fd93b8df7b2d3c3503a8e233e73f8dc2b956e8..a7f413a66d46354c803a60c69a32485d7935f17e 100644
--- a/docs/zh/server/_toc.yaml
+++ b/docs/zh/server/_toc.yaml
@@ -63,6 +63,8 @@ sections:
       - href: ./development/gcc/_toc.yaml
       - href: ./development/ai4c/_toc.yaml
       - href: ./development/fangtian/_toc.yaml
+      - href: ./development/bisheng_autotuner/_toc.yaml
+      - href: ./development/llvm/_toc.yaml
   - label: HA高可用
     sections:
       - href: ./high_availability/ha/_toc.yaml
diff --git a/docs/zh/server/development/bisheng_autotuner/_toc.yaml b/docs/zh/server/development/bisheng_autotuner/_toc.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..e89d0bc5653449464d3d907ba37026e9511e0176
--- /dev/null
+++ b/docs/zh/server/development/bisheng_autotuner/_toc.yaml
@@ -0,0 +1,6 @@
+label: BiSheng-Autotuner 用户指南
+isManual: true
+description: BiSheng-Autotuner 是一个自动编译调优工具，与支持调优的编译器（如 LLVM for openEuler、GCC for openEuler）配合使用
+sections:
+  - label: BiSheng-Autotuner 使用手册
+    href: ./bisheng_autotuner_user_guide.md
\ No newline at end of file
diff --git a/docs/zh/server/development/bisheng_autotuner/bisheng_autotuner_user_guide.md b/docs/zh/server/development/bisheng_autotuner/bisheng_autotuner_user_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..fbd86aa770c9db27798db4fa9c875dc10e757bda
--- /dev/null
+++ b/docs/zh/server/development/bisheng_autotuner/bisheng_autotuner_user_guide.md
@@ -0,0 +1,227 @@
+# BiSheng-Autotuner 使用手册
+
+## BiSheng-Autotuner 介绍
+
+[BiSheng-Autotuner](https://gitee.com/openeuler/BiSheng-Autotuner) 是一个基于 BiSheng-opentuner 的命令行工具，与支持调优的编译器（如 LLVM for openEuler、GCC for openEuler）配合使用。它负责生成搜索空间、操作参数并驱动整个调优过程。
+
+[BiSheng-opentuner](https://github.com/Huawei-CPLLab/bisheng-opentuner) 是一个开源框架，用于构建特定领域的、多目标程序的自动调优器。
+
+本文主要介绍基于 LLVM for openEuler 的自动调优编译流程，基于 GCC for openEuler 的自动调优请参考[AI4C 使用手册](..\ai4c\ai4c_user_manual.md)。
+
+## BiSheng-Autotuner 调优流程
+
+调优流程（如图1所示）由两个阶段组成：初始编译阶段（initial compilation）和调优阶段（tuning process）。
+
+![图1 BiSheng-Autotuner调优流程](figures/image1.png)
+
+图1 BiSheng-Autotuner调优流程
+
+### 初始编译阶段
+
+初始编译阶段发生在调优开始之前，BiSheng-Autotuner 首先会让编译器对目标程序代码做一次编译，在编译的过程中，编译器会生成一些包含所有可调优结构的 YAML 文件，告诉开发者在这个目标程序中哪些结构可以用来调优，比如模块（module）、函数（function）、循环（loop）。例如，循环展开是编译器中最常见的优化方法之一，它通过多次复制循环体代码，达到增大指令调度空间、减少循环分支指令开销的优化效果。若以循环展开次数（unroll factor）为对象进行调优，编译器会在 YAML 文件中生成所有可被循环展开的循环作为可调优结构。
+
+### 调优阶段
+
+当可调优结构顺利生成之后，调优阶段便会开始：
+
+1. BiSheng-Autotuner 首先读取生成好的可调优结构的 YAML 文件，从而产生对应的搜索空间，也就是生成针对每个可调优代码结构的具体的参数和范围。
+
+2. 调优阶段会根据设定的搜索算法尝试一组参数的值，生成一个 YAML 格式的编译配置文件（compilation config），从而让编译器编译目标程序代码产生二进制文件。
+
+3. 最后 BiSheng-Autotuner 将编译好的文件以开发者定义的方式运行并取得性能信息作为反馈。
+
+4. 经过一定数量的迭代之后，BiSheng-Autotuner 将找出最终的最优配置，生成最优编译配置文件，以 YAML 的形式储存。
+
+## BiSheng-Autotuner 使用
+
+### 环境要求
+
+必选：
+
+- 操作系统：openEuler 24.03 LTS 系列、openEuler 25.03 及高于 openEuler 25.03 的版本
+
+- 架构：AArch64、x86_64
+
+- Python 3.11.x
+
+- SQLite 3.0
+
+可选：
+
+- LibYAML：推荐安装，可提升 BiSheng-Autotuner 文件解析速度
+
+### BiSheng-Autotuner 获取
+
+若开发者使用最新的 openEuler 系统，可以直接安装 `BiSheng-Autotuner` 和 `clang` 软件包。
+
+```shell
+yum install -y BiSheng-Autotuner
+yum install -y clang
+```
+
+若需源码构建 `BiSheng-Autotuner` ，可以参考以下步骤。
+
+1. 安装 [BiSheng-opentuner](https://gitee.com/src-openeuler/BiSheng-opentuner/)
+
+    ```shell
+    yum install -y BiSheng-opentuner
+    ```
+
+2. 克隆并安装 [BiSheng-Autotuner](https://gitee.com/openeuler/BiSheng-Autotuner/)
+
+    ```shell
+    cd BiSheng-Autotuner
+    ./dev_install.sh
+    ```
+
+### BiSheng-Autotuner 运行
+
+本文将以 coremark 为示例展示如何运行自动调优, coremark 源码请从 [github 社区](https://github.com/eembc/coremark)获取。更多 llvm-autotune 的详细用法，请参阅[帮助信息](#帮助信息)章节。以下为以 20 次迭代调优 coremark 的脚本示例：
+
+```bash
+export AUTOTUNE_DATADIR=/tmp/autotuner_data/
+CompileCommand="clang -O2 -o coremark core_list_join.c core_main.c core_matrix.c core_state.c core_util.c posix/core_portme.c -DPERFORMANCE_RUN=1 -DITERATIONS=300000 -I. -Iposix -g -DFLAGS_STR=\"\""
+
+$CompileCommand -fautotune-generate;
+llvm-autotune minimize;
+for i in $(seq 20)
+do
+  $CompileCommand -fautotune ;
+  time=`{ /usr/bin/time -p ./coremark  0x0 0x0 0x66 300000; } 2>&1 | grep  "real" | awk '{print $2}'`;
+  echo "iteration: " $i "cost time:" $time;
+  llvm-autotune feedback $time;
+done
+llvm-autotune finalize;
+```
+
+以下为分步说明：
+
+1. 配置环境变量
+
+    使用环境变量 `AUTOTUNE_DATADIR` 指定调优相关的数据的存放位置（指定目录需要为空）。
+
+    ```shell
+    export AUTOTUNE_DATADIR=/tmp/autotuner_data/
+    ```
+
+2. 初始编译步骤
+
+    添加编译器选项 `-fautotune-generate` ，编译生成可调优代码结构。
+
+    ```shell
+    cd  examples/coremark/
+    clang -O2 -o coremark core_list_join.c core_main.c core_matrix.c core_state.c core_util.c posix/core_portme.c -DPERFORMANCE_RUN=1 -DITERATIONS=300000 -I. -Iposix -g -DFLAGS_STR=\"\" -fautotune-generate
+    ```
+
+    > [!WARNING]注意
+    > 建议仅将此选项应用于需要重点调优的热点代码文件。若应用的代码文件过多（超过 500 个文件），则会生成数量庞大的可调优代码结构的文件，进而可能导致步骤3的初始化时间长（可长达数分钟），以及巨大的搜索空间导致的调优效果不显著、收敛时间长等问题。
+
+3. 初始化调优
+
+    运行 `llvm-autotune` 命令，初始化调优任务。生成最初的编译配置供下一次编译使用。
+
+    ```shell
+    llvm-autotune minimize
+    ```
+
+    `minimize` 表示调优目标，旨在最小化指标（例如程序运行时间）。也可使用 `maximize` ，旨在最大化指标（例如程序吞吐量）。
+
+4. 调优编译步骤
+
+    添加毕昇编译器选项 `-fautotune` ，读取当前 `AUTOTUNE_DATADIR` 配置并编译。
+
+    ```shell
+    clang -O2 -o coremark core_list_join.c core_main.c core_matrix.c core_state.c core_util.c posix/core_portme.c -DPERFORMANCE_RUN=1 -DITERATIONS=300000 -I. -Iposix -g -DFLAGS_STR=\"\" -fautotune
+    ```
+
+5. 性能反馈
+
+    开发者运行程序，并根据自身需求获取性能数字，使用 `llvm-autotune feedback` 反馈。如果开发者想以 coremark 运行时间为指标进行调优，可以采用如下方式：
+
+    ```shell
+    time -p ./coremark  0x0 0x0 0x66 300000  2>&1 1>/dev/null | grep real | awk '{print $2}'
+    # 返回实际执行时间 31.09
+    ```
+
+    ```shell
+    llvm-autotune feedback 31.09
+    ```
+
+    > [!WARNING]注意
+    > 建议在使用 `llvm-autotune feedback` 之前， 先验证步骤 4 编译是否正常以及编译好的程序是否运行正确。若出现编译或者运行异常的情况，请输入相应调优目标的最差值（例如，调优目标为 minimize ，可输入 `llvm-autotune feedback 9999` ；maximize 可输入 0 或者 -9999）。
+    >
+    > 若输入的性能反馈不正确，可能会影响最终调优的结果。
+
+6. 调优迭代
+
+    根据开发者设定的迭代次数，重复4和5进行调优迭代。
+
+7. 结束调优
+
+    进行多次迭代后，开发者可选择终止调优，并保存最优的配置文件。配置文件会被保存在环境变量 `AUTOTUNE_DATADIR` 指定的目录下。
+
+    ```shell
+    llvm-autotune finalize
+    ```
+
+8. 最终编译
+
+    使用步骤7得到最优配置文件，进行最后编译。在环境变量未改变的情况下，可直接使用 `-fautotune` 选项：
+
+    ```shell
+    clang -O2 -o coremark core_list_join.c core_main.c core_matrix.c core_state.c core_util.c posix/core_portme.c -DPERFORMANCE_RUN=1 -DITERATIONS=300000 -I. -Iposix -g -DFLAGS_STR=\"\" -fautotune
+    ```
+
+    或者使用 `-mllvm -auto-tuning-input=` 直接指向配置文件。
+
+    ```shell
+    clang -O2 -o coremark core_list_join.c core_main.c core_matrix.c core_state.c core_util.c posix/core_portme.c -DPERFORMANCE_RUN=1 -DITERATIONS=300000 -I. -Iposix -g -DFLAGS_STR=\"\" -mllvm -auto-tuning-input=/tmp/autotuner_data/config.yaml
+    ```
+
+### 帮助信息
+
+llvm-autotune 执行格式如下所示：
+
+```shell
+llvm-autotune [-h] {minimize,maximize,feedback,dump,finalize}
+```
+
+可选指令：
+
+- `minimize`：初始化调优并生成初始的编译器配置文件，旨在最小化指标（例如运行时间）。
+
+- `maximize`：初始化调优并生成初始的编译器配置文件，旨在最大程度地提高指标（例如吞吐量）。
+
+- `feedback`：反馈性能调优结果并生成新的编译器配置。
+
+- `dump`：生成当前的最优配置，而不终止调优（可继续执行 `feedback`）。
+
+- `finalize`: 终止调优，并生成最佳的编译器配置（不可再执行 `feedback`）。
+
+### 编译器相关选项
+
+llvm-autotune 需要与 LLVM 编译器选项 `-fautotune-generate` 和 `-fautotune` 配合使用。
+
+- `-fautotune-generate`：
+
+    - 在 `autotune_datadir` 目录下生成可调优的代码结构列表，此默认目录可由环境变量 `AUTOTUNE_DATADIR` 改写。
+
+    - 作为调优准备工作的第一步，通常需要在 `llvm-autotune minimize/maximize` 命令执行前使用。
+
+    - 此选项还可以赋值来改变调优的颗粒度（可选值为`Other`、`Function`、`Loop`、`CallSite`、`MachineBasicBlock`、`Switch`、`LLVMParam`、`ProgramParam`，其中 `LLVMParam` 和 `ProgramParam` 对应粗粒度选项调优）。例如 `-fautotune-generate=Loop` 会开启类型仅为循环的可调优代码结构，每个循环在调优过程中会被赋予不同的参数值；而 `Other` 表示全局，生成的可调优代码结构对应每个编译单元（代码文件）。
+
+    - `-fautotune-generate`默认等效于`-fautotune-generate=Function,Loop,CallSite`。通常建议使用默认值。
+
+    - 若要启用选项调优（`LLVMParam`和`ProgramParam`），需要为 llvm-autotune 指定拓展搜索空间，默认的搜索空间不包含预设调优选项。
+
+        ```shell
+        llvm-autotune minimize --search-space /usr/lib64/python<version>/site-packages/autotuner/search_space_config/extended_search_space.yaml
+        ```
+
+        `site-packages`目录可以通过 `pip show autotuner` 指令找到。
+
+- `-fautotune`：
+
+    - 使用`autotune_datadir`下的编译器配置进行调优编译（此默认目录可由环境变量`AUTOTUNE_DATADIR`改写）。
+
+    - 通常在调优迭代过程中，`llvm-autotune minimize/maximize/feedback` 命令之后使用。
diff --git a/docs/zh/server/development/bisheng_autotuner/figures/image1.png b/docs/zh/server/development/bisheng_autotuner/figures/image1.png
new file mode 100644
index 0000000000000000000000000000000000000000..10e002c1402574e3e5b1f9d4f050efb4f439c22e
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/figures/image1.png differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-caution.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-caution.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-caution.gif differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-danger.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-danger.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-danger.gif differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-note.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-note.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-note.gif differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-notice.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-notice.gif
new file mode 100644
index 0000000000000000000000000000000000000000..86024f61b691400bea99e5b1f506d9d9aef36e27
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-notice.gif differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-tip.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-tip.gif
new file mode 100644
index 0000000000000000000000000000000000000000..93aa72053b510e456b149f36a0972703ea9999b7
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-tip.gif differ
diff --git a/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-warning.gif b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-warning.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/bisheng_autotuner/public_sys-resources/icon-warning.gif differ
diff --git a/docs/zh/server/development/llvm/_toc.yaml b/docs/zh/server/development/llvm/_toc.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..90b3354d795b0ede9e2a2c27c4faa62afe326844
--- /dev/null
+++ b/docs/zh/server/development/llvm/_toc.yaml
@@ -0,0 +1,12 @@
+label: LLVM用户指南
+isManual: true
+description: LLVM for openEuler 编译器基于开源 LLVM 开发
+sections:
+  - label: LLVM 反馈优化用户指南
+    href: ./llvm_pgo_user_guide.md
+  - label: 内核反馈优化特性用户指南
+    href: ./kernel_pgo_user_guide.md
+  - label: GNU 兼容性用户指南
+    href: ./gnu_compatibility_user_guide.md
+  - label: 新增架构支持
+    href: ./more_architecture_supported.md
\ No newline at end of file
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_0.png b/docs/zh/server/development/llvm/figures/figure_pgo_0.png
new file mode 100644
index 0000000000000000000000000000000000000000..8a4bc807f1579202d2df5fbcca592edea6cb70b2
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_0.png differ
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_1.png b/docs/zh/server/development/llvm/figures/figure_pgo_1.png
new file mode 100644
index 0000000000000000000000000000000000000000..db068a1491b6ae2b313f19213da50219e3ab3bc8
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_1.png differ
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_2.png b/docs/zh/server/development/llvm/figures/figure_pgo_2.png
new file mode 100644
index 0000000000000000000000000000000000000000..e7096da9e3f6e6ebe4c159ace8078b568785a605
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_2.png differ
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_3.png b/docs/zh/server/development/llvm/figures/figure_pgo_3.png
new file mode 100644
index 0000000000000000000000000000000000000000..c38cae90f81b4f4ecfb1072dcb30f9df72b42c51
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_3.png differ
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_4.png b/docs/zh/server/development/llvm/figures/figure_pgo_4.png
new file mode 100644
index 0000000000000000000000000000000000000000..7f437a1a8f33ebbc1fc79e4d43c700204b536e97
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_4.png differ
diff --git a/docs/zh/server/development/llvm/figures/figure_pgo_5.png b/docs/zh/server/development/llvm/figures/figure_pgo_5.png
new file mode 100644
index 0000000000000000000000000000000000000000..9068cb0d90b369710d3e1b24a92dd838563310d3
Binary files /dev/null and b/docs/zh/server/development/llvm/figures/figure_pgo_5.png differ
diff --git a/docs/zh/server/development/llvm/gnu_compatibility_user_guide.md b/docs/zh/server/development/llvm/gnu_compatibility_user_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..9d6823f8fc637c33773411e7dc52d9c858d8538d
--- /dev/null
+++ b/docs/zh/server/development/llvm/gnu_compatibility_user_guide.md
@@ -0,0 +1,675 @@
+# GNU 兼容性用户指南
+
+## 简介
+
+相比 GNU 编译器，LLVM 前端 Clang 对语法的检查更严谨，严格匹配语言标准，Clang 的常见兼容性和可移植性问题，请参考[开源官方文档](https://clang.llvm.org/compatibility.html) 。本文主要列出一些 LLVM for openEuler 相对 GNU 编译器不支持的问题以及部分固有实现，以供用户参考。LLVM for openEuler 针对 GNU 编译器进行了一定程度的兼容，并提供针对 GNU 编译器的整体兼容选项 `-fGNU-compatibility`。
+
+## -Werror 引入的问题
+
+### 错误信息
+
+在编译选项打开 `-Werror` 的情况下，编译器会将所有 warning 转化为 error，不同于 warning，error 会阻碍构建。此类 error 格式如下：
+
+```shell
+test.c:6:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
+```
+
+### 问题介绍
+
+因为 LLVM 编译器和 GNU 编译器对于 warning 的处理有差异，因此可能存在切换 LLVM 后，新增 warning 并被 `-Werror` 选项转化为 error，阻碍构建的情况。
+
+### 解决方案
+
+可以通过增加 `-Wno` 选项关闭对应的 warning，例如上例中 warning 提示告警来自 `-Wreturn-type` 选项，则可添加 `-Wno-return-type`（`W` 后添加 `no-`）选项关闭该告警，可以通过在源码根目录 `grep -Werror` 找到设置 `-Werror` 选项的位置，并在该处添加对应的 `-Wno` 选项。openEuler 中的 LLVM17 版本可通过打开 `-fGNU-compatibility` 选项，控制大部分与 GNU 编译器存在差异的 warning 不被 `-Werror` 选项升级，批量解决该问题。
+
+## 选项兼容问题
+
+### 问题介绍
+
+因为 LLVM 编译器和 GNU 编译器支持的选项功能存在差异，因此可能存在切换 LLVM 后，部分编译选项不识别导致报错。
+
+包括但不限于：
+
+```shell
+-znow
+# error: unknown argument: `-znow`
+
+-mabi=lp64
+# error: unknown target ABI 'lp64'
+
+clang -std=c++11
+# error: invalid argument '-std=c++11' not allowed with 'C'
+
+-Wa,--generate-missing-build-notes=yes
+# clang: error: unsupported argument '--generate-missing-build-notes=yes' to option '-Wa,'
+```
+
+### 解决方式
+
+1. 去除相关选项或使用 LLVM 支持的相关选项替代。
+
+2. openEuler 中的 LLVM17 版本包含一系列选项兼容适配特性，使用部分选项编译时会自动适配 GNU 行为，避免生成阻塞性告警。
+
+## Clang 不支持问题
+
+### 不支持 print-multi-os-directory
+
+#### 错误信息
+
+```shell
+ERROR: Problem encountered: Cannot find elf_aarch64_efi.lds
+```
+
+#### 问题介绍
+
+GCC 使用 `print-multi-os-directory`，该选项返回 `../lib64`，而 Clang 不支持该选项，故无法组成完整的路径，因此找不到某些文件。
+
+#### 解决方案
+
+在编译时，对需要通过选项获取 lib 路径的代码进行硬编码。
+
+### 不支持 __builtin_longjmp/__builtin_setjmp
+
+#### 错误信息
+
+```shell
+error: __builtin_longjmp is not supported for the current target 
+  __builtin_longjmp (buf, 1); 
+  ^~~~~~~~~~~~~~~~~~~~~~~~~~ 
+error: __builtin_setjmp is not supported for the current target 
+  int r = __builtin_setjmp (buf); 
+          ^~~~~~~~~~~~~~~~~~~~~~
+```
+
+#### 问题介绍
+
+当前 AArch64 后端不支持内置函数 `__builtin_longjmp` 和 `__builtin_setjmp`。
+
+#### 解决方案
+
+- 使用标准库中的setjmp/longjmp。
+
+- 编译器后续支持。
+
+### 32 位下不支持 __uint128_t
+
+#### 错误信息
+
+```shell
+clang: warning: unknown platform, assuming -mfloat-abi=soft 
+error: unknown type name '__uint128_t'
+```
+
+#### 问题介绍
+
+在 32 位模式下编译（例如添加了 `-m32` 参数）报错：`__uint128` 不被支持。
+
+除此之外，还可能看到一个平台无法识别的 warning：使用 `-mfloat-abi=soft` 参数将浮点运算编译为软浮点。
+
+#### 解决方案
+
+- 去除 `-m32` 参数，使用 64 位模式编译；
+
+- 检查 Makefile、configure 等构建脚本的平台判断流程，使用正确的平台选项编译。
+
+### 不支持选项 -aux-info
+
+#### 错误信息
+
+无报错信息
+
+#### 问题介绍
+
+`-aux-info` 选项用于将编译单元中声明或定义的所有函数（包括头文件中的函数）输出到给定的输入文件。
+
+该选项一般用于从 `*.c` 自动生成 `*.h` 文件。
+
+Clang 不支持这个选项。
+
+#### 解决方案
+
+避免使用 Clang 不支持的选项。
+
+如果确实需要这些信息，可以通过预处理器处理之后，用 `sed/aux` 等命令提取出想要的函数信息。
+
+例如：
+
+```shell
+clang -E -xc test.c | sed -n 's/^extern * int *\(\w*\) *(.*$/\1/p'
+```
+
+### 不支持 __builtin___snprintf_chk
+
+#### 错误信息
+
+```shell
+error: no member named '__builtin___snprintf_chk' in
+```
+
+#### 问题介绍
+
+Clang 暂不支持检查 built-in 函数格式化输出，会报出 warning，当开启 `-Werror` 选项时升级为 error。
+
+#### 解决方案
+
+添加编译选项-Wno-builtin-memcpy-chk-size规避该告警
+
+### 不支持 NEON 指令
+
+#### 错误信息
+
+```shell
+error: unknown register name 'q0' in asm 
+        : "memory", "cc", "q0" 
+                          ^
+```
+
+#### 问题介绍
+
+Clang 中不支持 NEON 指令 Q 寄存器设计
+
+代码示例
+
+```shell
+$ cat bar.c 
+int foo(void) { 
+    __asm__("":::"q0"); 
+    return 0; 
+} 
+$ clang bar.c  
+bar.c:2:16: error: unknown register name 'q0' in asm 
+    __asm__("":::"q0"); 
+               ^ 
+1 error generated.
+```
+
+#### 解决方案
+
+修改 `qX` 寄存器为 `vX` 寄存器。
+
+### 不支持部分运行库
+
+#### 错误信息
+
+```shell
+undefined reference to `__muloti4'
+```
+
+#### 问题介绍
+
+某符号不在 libgcc 中，但是在 compiler-rt 中，特别是使用 Clang 的 `__builtin_*_overflow` 家族的内联函数时。
+
+#### 解决方案
+
+使用 `--rtlib=compiler-rt` 来启用 compiler-rt ，注意目前并不支持所有平台。
+
+如果使用 libc++ 或者 libc++abi，使用 compiler-rt 而不是 libgcc_s，通过在 cmake 中添加 `-DLIBCXX_USE_COMPILER_RT=YES` 和 `-DLIBCXXABI_USE_COMPILER_RT=YES` 实现。否则可能会链接两个运行时库，虽然不影响功能但是造成性能浪费。
+
+参考 [LLVM 官方说明](https://clang.llvm.org/docs/Toolchain.html)。
+
+### 不支持原子类型（atomic type）的类型转换
+
+#### 错误信息
+
+```shell
+error: used type '_Atomic(int_fast32_t)' where arithmetic or pointer type is required 
+                uint32_t(_Atomic(int_fast32_t))(1) 
+                        ^
+```
+
+#### 问题介绍
+
+Clang 拒绝对非标准类型的类型转换，并且目前不支持对原子类型（atomic type）的转换。所支持的类型在 `clang/include/clang/AST/BuiltinTypes.def` 中有列出，不包括原子类型。
+
+#### 解决方案
+
+避免对原子类型使用类型转换。
+
+## 链接问题
+
+### 指定 pic、pie
+
+#### 错误信息
+
+某些动态库在未使用 pic/pie 选项的情况下，会报符号表缺失的错误，比如：
+
+```shell
+undefined reference to `cmsPlugin'
+```
+
+#### 问题介绍
+
+生成动态库与 pie 可执行文件编译或链接时未带对应 pic/pie 选项，导致符号表缺失，需要手动指定。
+
+#### 代码示例
+
+执行如下命令检查是否为 PIC 库，检索到 textrel 符号则表明是 PIC 库。
+
+```shell
+readelf -a libhello.so |grep -i textrel
+```
+
+检查是否为 PIE 共享文件，使用 `file` 命令查看，或者用 `size --format=sysv` 查看基地址是否在 0 附近。
+
+#### 解决方案
+
+编译选项增加 `-fPIC`，链接选项增加 `-pie`。
+
+> [!WARNING]注意
+> Clang 严格区分编译和链接选项，不能通过 cflags 将 `-pie` 传递给链接器，否则会报错：
+> `clang: error: argument unused during compilation: '-pie' [-Werror,-Wunused-command-line-argument]`
+
+### 给链接器参数加上 -Wl
+
+#### 错误信息
+
+```shell
+clang: error: unsupported option `--whole-archive` 
+clang: error: unsupported option `--no-whole-archive` 
+clang: error: unknown argument: `-soname`
+```
+
+#### 问题介绍
+
+部分应用构建脚本在编译器为 clang 时可能不会默认给需要传递给链接器加上 `-Wl`，这部分参数必须添加 `-Wl`，才能传递给链接器。
+
+包括但不限于：
+
+```shell
+--whole-archive
+--no-whole-archive
+-soname
+```
+
+如果出现 `unknown argument` 或者 `unsupported option` ，并且该选项是应该传给链接器的，则需要加上 `-Wl`。
+
+#### 解决方案
+
+这些参数前面添加 `-Wl,`。例如：
+
+```shell
+-Wl,--whole-archive -Wl,--no-whole-archive -Wl,-soname
+```
+
+### Clang 不再默认传递 --build-id 到链接器
+
+#### 错误信息
+
+```shell
+ERROR: No build ID note found in xxx.so
+```
+
+#### 问题介绍
+
+为了避免额外链接器开销，Clang 不再默认传递 `--build-id` 到链接器。
+
+#### 解决方案
+
+编译目标源码时增加 `-Wl,--build-id` 选项可以临时传递。
+
+### 系统 libstdc++ 库版本过低导致符号未定义或运行结果错误
+
+#### 错误信息
+
+无法找到高版本 C++ 标准库函数定义的接口：
+
+```shell
+undefined reference to `std::xxx`
+```
+
+#### 问题介绍
+
+Clang 默认使用系统路径下的 `libstdc++.so` 动态库，过低的系统 `libstdc++.so` 库版本可能不支持用户代码中使用的高版本特性，导致链接时出现未定义符号或运行结果错误。
+
+#### 解决方案
+
+链接时加入 `-stdlib=libc++` 或 `-lc++` 选项，使用 Clang 提供的 `libc++.so` 库中提供的标准 C++ 库实现。
+
+### 系统 binutils 版本过低导致 debug_info 段链接失败
+
+#### 错误信息
+
+```shell
+unable to initializedecompress status for section .debug_info
+```
+
+#### 问题介绍
+
+在 x86_64 环境 CentOS 7.6、Ubuntu 18.04 系统上运行时，如果系统默认的 binutils 版本低于 2.32，会由于低版本 binutils 对调试信息段的对齐处理有误，导致在链接时如果链接由高版本（版本 >2.32）binutils 生成的 debug_info 段链接失败。
+
+#### 解决方案
+
+1. 在链接时使用 `-fuse-ld=lld` 选项，选择 LLVM for openEuler 自带的链接器即可。
+
+2. 如仍然需要 GNU 链接器，请升级系统链接器到 2.32 版本以上。
+
+## 其他类兼容问题
+
+### Clang 预处理器结果与 GCC 存在较大差异
+
+#### 错误信息
+
+- 格式错误：syntax error, unexpected IDENT
+
+- 找不到头文件等
+
+#### 问题介绍
+
+Clang 的预处理器实现和 GCC 有比较大的不同，例如：
+
+- Clang 会保留每行开头的空白符。
+
+- Clang 会保留引入的头文件的绝对路径。
+
+其它的不一一列举。
+
+有一些程序会使用预处理器来处理源码文件，但是因为Clang和GCC的预处理器的行为有一些不同，可能会因此导致一些问题。
+
+#### 解决方案
+
+修改源码使得其能被 Clang 的预处理器正确处理。例如：
+
+- 删除代码行前的空白符。
+
+- 保证include的文件能被找到。
+
+### Clang不支持在使用'-o'指定输出时直接添加头文件
+
+#### 错误信息
+
+```shell
+clang test.h test.c -o test 
+clang: error: cannot specify -o when generating multiple output files
+```
+
+#### 问题介绍
+
+Clang 不支持在使用 `-o` 指定输出文件时直接添加头文件，但允许在编译命令中使用预编译头文件，以减少编译时间。
+
+```shell
+$ cat test.c
+#include "test.h"
+```
+
+生成预编译头文件的命令：
+
+```shell
+clang -x c-header test.h -o test.h.pch
+```
+
+可以通过添加 `-include` 命令使用预编译头文件：
+
+```shell
+clang -include test.h test.c -o test
+```
+
+Clang 会先检查 `test.h` 对应的预编译头文件是否存在；如果存在，则会使用对应的预编译头文件对 `test.h` 进行处理，否则，Clang 会直接处理 `test.h` 的内容。
+
+如果设法在 Clang 编译命令中保留头文件，则可以通过添加命令 `-include` 的方法使其通过编译。
+
+[官方参考文档](https://clang.llvm.org/docs/UsersManual.html)
+
+#### 解决方案
+
+避免在 Clang 的编译命令中直接添加头文件，或者按照上述方法使用预编译功能。
+
+### 不同编译器对 built-in includes 的实现不同
+
+#### 错误信息
+
+```shell
+error: typedef redefinition with different types ('__uint64_t' (aka 'unsigned long') vs 'UINT64' (aka 'unsigned long long')) 
+error: unknown type name 'wchar_t'
+```
+
+#### 问题介绍
+
+某些头文件（例如 `stdatomic.h`、`stdint.h` ）是由编译器实现的，不同的编译器对于这些文件的实现存在差异，因此使用 GCC 头文件实现的程序，切换到 Clang 之后，用户自定义的代码可能会与 Clang 头文件发生冲突。
+
+比如说重定义问题：在 Clang 的某些头文件中定义了一些在对应 GCC 的头文件中没有定义的变量，而用户在自己编写的或引入的其它库的头文件也定义了该变量，变量被重复定义，导致 redefinition 错误。
+
+又或者：在 GCC 的 built-in 头文件中定义了一些变量，而 Clang 对应的头文件中没有定义该变量，用户在自己编写的代码中直接使用了该变量，结果就会导致 unknown type 的错误。
+
+#### 解决方案
+
+建议修改源码。
+
+### 不同编译器链接的OpenMP运行时库不同
+
+#### 错误信息
+
+- 测试错误
+
+- 无法加载OpenMP运行时库
+
+#### 问题介绍
+
+Clang 编译的可执行程序链接的 OpenMP 运行时库叫 `libomp.so`，GCC 链接的叫 `libgomp.so`。
+
+#### 解决方案
+
+确保能够找到 `libomp.so`。
+
+- 将 `libomp.so` 所在的目录（例如 `{$INSTALLATION_HOME}/lib，INSTALLATION_HOME` 为安装根目录）添加到环境变量 `LD_LIBRARY_PATH`。
+
+- 或者安装libomp：
+
+    ```shell
+    yum install libomp -y
+    ```
+
+### __builtin_prefetch 语义检查错误
+
+#### 错误信息
+
+```shell
+ error: argument to '__builtin_prefetch' must be a constant integer 
+    __builtin_prefetch(address, forWrite); 
+    ^
+```
+
+#### 问题介绍
+
+在这段代码中，因为 `__builtin_prefetch` 的第二个参数需要是常量，所以先用 `__builtin_constant_p` 检查 `forWrite` 是否是常量。但是，对于 Clang 而言，会出现语义检查错误。
+
+#### 代码示例
+
+```c
+static void prefetchAddress(const void *address, bool forWrite) { 
+    if (__builtin_constant_p(forWrite)) { 
+        __builtin_prefetch(address, forWrite); 
+    } 
+}
+```
+
+#### 解决方案
+
+将函数转换为宏函数：
+
+```c
+##define prefetchAddress(address,forWrite) do{\ 
+  if (__builtin_constant_p(forWrite)) {      \ 
+    __builtin_prefetch(address, forWrite);   \ 
+  }                                          \ 
+}while(0)
+```
+
+### 找不到符号 perl_tsa_mutex_lock
+
+#### 错误信息
+
+```shell
+Can't load 'xxx.so' for module threads: xxx.so: undefined symbol: perl_tsa_mutex_lock at xxx
+```
+
+#### 问题介绍
+
+在文件 `/usr/lib64/perl5/CORE/perl.h` 中有如下的定义：
+
+```c
+##if ... 
+    defined(__clang__) 
+    ... 
+##  define PERL_TSA__(x)   __attribute__((x)) 
+##  define PERL_TSA_ACTIVE 
+##else 
+##  define PERL_TSA__(x)   /* No TSA, make TSA attributes no-ops. */ 
+##  undef PERL_TSA_ACTIVE 
+##endif 
+ 
+##ifdef PERL_TSA_ACTIVE 
+EXTERN_C int perl_tsa_mutex_lock(perl_mutex* mutex) 
+  PERL_TSA_ACQUIRE(*mutex) 
+  PERL_TSA_NO_TSA; 
+EXTERN_C int perl_tsa_mutex_unlock(perl_mutex* mutex) 
+  PERL_TSA_RELEASE(*mutex) 
+  PERL_TSA_NO_TSA; 
+##endif##endif
+```
+
+由于针对 Clang 使用的 mutex 相关的符号是有线程安全标记的 `perl_tsa_*`，但是 `libperl.so` 并不包含这些符号，故而出现链接错误。
+
+#### 解决方案
+
+- 使用包含 `perl_tsa_*` 符号的 `libperl.so`（在编译 `libperl.so` 时，加上宏 `USE_ITHREADS` 和 `I_PTHREAD`）。
+
+- 去除预定义宏 `__clang__`：
+
+    ```c
+    clang -U__clang__ ...
+    ```
+
+### Clang 宏问题
+
+#### 问题介绍
+
+程序代码逻辑使用了 `__GNUC__` 的宏作为判断依据，但是 GCC 与 Clang 中定义的宏内容不一致，可以使用如下命令确认 Clang 中宏定义的值。
+
+```shell
+clang -x c /dev/null -dM -E >clang.log;cat clang.log|grep '__GNUC__'
+```
+
+#### 解决方案
+
+若宏内容不一致导致报错，可以在编译选项加入 `-D__GNUC__=x` 进行适配修改。
+
+### 支持的 Attributes 集合
+
+LLVM for openEuler 只支持 Clang 框架中的 attributes，请参考[clang文档](https://clang.llvm.org/docs/AttributeReference.html)
+
+链接中未提到 attributes 暂不支持。
+
+### -march 选项在架构扩展特性上的使用说明
+
+Clang 使用架构扩展特性时，需在 `-march=<arch_name>` 后加上扩展特性的名称，包括架构默认支持的扩展特性。例如，DotProd 特性是 Armv8.4 架构默认支持的，可使用 `-march=armv8.4-a+dotprod` 使能该特性。
+
+### -mgeneral-regs-only 选项的使用说明
+
+使用该选项时将生成仅使用通用寄存器的代码，这会阻止编译器使用浮点或高级 SIMD 寄存器。因此当编译时加入该选项，编译器应避免使用浮点运算指令，如果程序中有浮点运算，LLVM for openEuler 将会调用 compiler-rt 中的库函数进行运算。因此，链接时要配合添加 `-rtlib=compiler-rt -l gcc_s` 选项。
+
+### Hardware-assisted AddressSanitizer 仅支持在基于 Linux5.4 及以上内核版本的 OS 上运行
+
+Hardware-assisted AddressSanitizer 可以通过 `-fsanitize=hwaddress -fuse-ld=lld` 使能，该特性依赖一部分 Linux5.4 及以上才支持的内核接口，若环境内核版本低于 5.4 则无法正常使能，这种情况下建议使用常规地址消毒。
+
+### Neon Intrinsic
+
+Neon Intrinsic 和编译器的具体实现相关，Clang 的neon Intrinsic 的功能与官方文档[《Arm Neon Intrinsics Reference》](https://developer.arm.com/documentation/ihi0073/g)（以下简称ANIR文档）一致。
+
+但生成 ANIR 文档上指定的汇编指令，需指定优化级别大于 O0。
+
+#### 使用举例
+
+以内容如下的test.c为例：
+
+```c
+#include <arm_neon.h>
+int32x2_t test_vsudot_lane_s32(int32x2_t r, int8x8_t a, uint8x8_t b) {
+    return vsudot_lane_s32(r, a, b, 0);
+}
+```
+
+表1 ANIR文档上vsudot_lane_s32的描述
+
+| Intrinsic | Argument Preparation | Instruction | Result |Supported Architectures |
+|-|-|-|-|-|
+| int32x2_t vsudot_lane_s32(int32x2_t r, int8x8_t a, uint8x8_t b, const int lane) | r -\> Vd.2S <br /> a -\> Vn.8B <br /> b -\> Vm.4B <br /> 0 \<= lane \<= 1 | SUDOT Vd.2S,Vn.8B,Vm.4B[lane] | Vd.2S -\> result | A32/A64 |
+
+使用命令 `clang -march=armv8.6-a+i8mm test.c -O0 -S` 生成的结果是以 mov、dup 和 usdot 等多条指令组合的形式。
+
+```asm
+test_vsudot_lane_s32:                   // @test_vsudot_lane_s32
+// %bb.0:                               // %entry
+        sub     sp, sp, #112            // =112
+        str     d0, [sp, #72]
+        str     d1, [sp, #64]
+        str     d2, [sp, #56]
+        ldr     d0, [sp, #72]
+        str     d0, [sp, #48]
+        ldr     d0, [sp, #64]
+        str     d0, [sp, #40]
+        ldr     d0, [sp, #56]
+        str     d0, [sp, #32]
+        ldr     d0, [sp, #32]
+        str     d0, [sp, #16]
+        ldr     d0, [sp, #48]
+        ldr     d1, [sp, #16]
+                                        // implicit-def: $q3
+        mov     v3.16b, v1.16b
+        dup     v1.2s, v3.s[0]
+        ldr     d2, [sp, #40]
+        str     d0, [sp, #104]
+        str     d1, [sp, #96]
+        str     d2, [sp, #88]
+        ldr     d0, [sp, #104]
+        ldr     d1, [sp, #96]
+        ldr     d2, [sp, #88]
+        usdot   v0.2s, v1.8b, v2.8b
+        str     d0, [sp, #80]
+        ldr     d0, [sp, #80]
+        str     d0, [sp, #24]
+        ldr     d0, [sp, #24]
+        str     d0, [sp, #8]
+        ldr     d0, [sp, #8]
+        add     sp, sp, #112            // =112
+        ret
+```
+
+使用命令 `clang -march=armv8.6-a+i8mm test.c -O1 -S` 生成结果与 ANIR 文档一致。
+
+```asm
+test_vsudot_lane_s32:                   // @test_vsudot_lane_s32
+// %bb.0:                               // %entry
+                                        // kill: def $d2 killed $d2 def $q2
+        sudot   v0.2s, v1.8b, v2.4b[0]
+        ret
+```
+
+## OpenMP兼容性
+
+### linear 子句和 chucked dynamic schedule 子句共用不支持
+
+当 `linear` 子句和 `chucked dynamic schedule` 子句一起使用时，OpenMP 不支持该场景的线程调度，导致运行后循环的线性变量的值不正确。
+
+该场景已提交到[上游社区](https://github.com/llvm/llvm-project/issues/61230)，等待社区进行修复。
+
+规避方案是可以使用其它子句来替换，或者不使用 `chucked dynamic schedule` 的线程调度方式。
+
+### Omp atomic 特性依赖 10.3.0 及以上的系统 GCC 版本
+
+Omp atomic 特性依赖系统 GCC 的 libgcc，低于 10.3.0 的系统 GCC 版本可能引发运行结果异常。如果需要使用请保证系统 GCC 版本满足要求。使用 Omp atomic 特性的具体用例如下：
+
+```c
+void foo(double *Ptr, double M, double N) {
+    double sum = 0;
+    #pragma omp parallel for
+    for (int i = 0; i < 100; ++i){
+        Ptr[i] = i+(M*2 + N);
+        #pragma omp atomic
+        sum += Ptr[i];
+    }
+}
+```
+
+## 问题反馈
+
+在使用过程中遇到问题，需要技术支持时，请反馈问题信息至 openEuler 社区 [llvm-project](https://gitee.com/openeuler/llvm-project) 源码仓。
diff --git a/docs/zh/server/development/llvm/kernel_pgo_user_guide.md b/docs/zh/server/development/llvm/kernel_pgo_user_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..2334e114e9db303f434e3ada06257c3fa687e064
--- /dev/null
+++ b/docs/zh/server/development/llvm/kernel_pgo_user_guide.md
@@ -0,0 +1,85 @@
+# 内核反馈优化特性用户指南
+
+## 简介
+
+[PGO(Profile-Guided Optimization)](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization)是一种编译器反馈优化技术，通过收集程序运行时的信息，指导编译器的优化决策。内核反馈优化（PGO kernel）特性为内核提供了反馈优化能力的支持，使用户可以为不同的应用程序构建针对性优化的内核，在单应用场景下提高目标应用的性能。根据业界经验，对于数据中心大型应用（如MySQL、Nginx、Redis等）通过PGO优化应用和内核有较好的效果。
+
+## 环境准备
+
+### 软件要求
+
+* 操作系统：openEuler 24.03 LTS (SP1)
+* clang、llvm、lld：17.0.6
+
+### 硬件要求
+
+* AArch64架构
+* x86_64架构
+
+### 安装软件
+
+安装内核源码、编译工具链及其他依赖包：
+
+```bash
+yum install -y kernel-source clang llvm lld flex bison rpm-build elfutils-libelf-devel dwarves openssl-devel rsync
+```
+
+复制内核源码：
+
+```bash
+cp -r /usr/src/linux-6.6.0-54.0.0.57.oe2403.aarch64 .
+```
+
+> [!WARNING]注意
+>
+> 具体版本号可能有变化。
+
+## 使用方法
+
+和一般的插桩式反馈优化类似，这里也先构建一个插桩版本，使用编译器插入的探针收集运行时信息并写入到文件，使用收集到的文件二次构建，指导编译器的优化决策。
+
+### 插桩版本构建
+
+```bash
+make LLVM=1 LLVM_IAS=1 openeuler_defconfig
+scripts/config -e PGO_CLANG
+make LLVM=1 LLVM_IAS=1 binrpm-pkg -j$(getconf _NPROCESSORS_ONLN)
+```
+
+### 安装插桩版本内核并重启
+
+```bash
+rpm -ivh kernel-6.6.0-1.aarch64.rpm # 注意文件名可能不同
+grub2-reboot 0                      # 指定下一次重启的启动项为刚安装的内核
+reboot
+```
+
+### 收集profile信息
+
+重置数据：
+
+```bash
+echo 1 > /sys/kernel/debug/pgo/reset
+```
+
+运行程序后，获取采集到的profile信息：
+
+```bash
+cp -a /sys/kernel/debug/pgo/vmlinux.profraw /tmp/vmlinux.profraw
+llvm-profdata merge /tmp/vmlinux.profraw -o vmlinux.profdata
+```
+
+### 二次构建
+
+```bash
+make LLVM=1 LLVM_IAS=1 openeuler_defconfig
+make LLVM=1 LLVM_IAS=1 KCFLAGS=-fprofile-use=/the/profile/data/path/vmlinux.profdata binrpm-pkg -j$(getconf _NPROCESSORS_ONLN)
+```
+
+### 安装优化版本内核并重启
+
+```bash
+rpm -ivh kernel-6.6.0-2.aarch64.rpm
+grub2-reboot 0
+reboot
+```
diff --git a/docs/zh/server/development/llvm/llvm_pgo_user_guide.md b/docs/zh/server/development/llvm/llvm_pgo_user_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..aacc8185eda35664edb9dc23e9f1af0c69230b7b
--- /dev/null
+++ b/docs/zh/server/development/llvm/llvm_pgo_user_guide.md
@@ -0,0 +1,80 @@
+# LLVM 反馈优化用户指南
+
+## PGO 简介
+
+PGO （Profile-Guided Optimization）是一种编译器优化技术。它通过在程序运行时收集性能数据，并在编译阶段使用这些数据来优化程序的性能。PGO 需要两次编译过程，第一次编译时在应用代码中插桩，通过运行典型用例和业务，收集应用代码中函数及分支的执行次数信息，第二次编译时根据运行统计信息近一步优化，生成高性能应用。PGO 等反馈优化技术在数据库、分布式存储等数据和计算密集型等前端瓶颈较高的场景效果显著，性能可提升 10%~30%。它能够有效减少计算时间和资源消耗，提升应用性能，显著降低运营成本并提高用户体验。
+
+![alt text](figures/figure_pgo_0.png)
+
+## 优化原理
+
+传统编译优化只能通过静态的程序分析及启发式算法预测程序的执行行为。PGO 通过采集程序运行时信息，可以精准的判断代码的冷热、执行的概率，从而完成高效的冷热分区、分支预测、函数重排、寄存器分配、向量化、函数内联等优化，提升 cache 命中率、分支命中率和数据并行度，减少寄存器压力。
+
+典型优化原理说明如下：
+
+1. 冷热分区
+
+    剥离冷分支，使热点代码聚合，提升 cache 命中率。
+
+    ![alt text](figures/figure_pgo_1.png)
+
+2. 函数重排
+
+    代码段函数重排，使热点函数聚合，降低 iTLB 及 icache miss。
+
+    ![alt text](figures/figure_pgo_2.png)
+
+3. 分支预测
+
+    调整分支顺序，降低 branch miss 率。
+
+    ![alt text](figures/figure_pgo_3.png)
+
+4. 函数内联
+
+    基于反馈的 inline：全局分析，精准内联，优化调用栈，内存排布更优。
+
+    ![alt text](figures/figure_pgo_4.png)
+
+5. switch优化
+
+    结构分支调整，减少跳转，降低 branch miss 率。
+
+    ![alt text](figures/figure_pgo_5.png)
+
+## 优化效果
+
+数据库场景： MySQL、GaussDB 等数据库应用，使用 LLVM LTO+PGO 优化，性能提升 20%~30%。
+
+分布式存储：Ceph、LAVA 等分布式存储解决方案，使用 LLVM LTO+PGO 优化，性能提升 10%+。
+
+## 使用方法
+
+1. 增加编译选项 `-fprofile-generate=$PROFILE_DATA_PATH`（`$PROFILE_DATA_PATH` 为用于存放采样文件的路径）编译源码得到可执行文件。
+
+2. 给可执行文件一组有代表性的输入，并运行可执行文件进行采样，采样后在 `$PROFILE_DATA_PATH` 路径下会得到 `xxxx.profraw` 采样文件。
+
+3. `cd $PROFILE_DATA_PATH` ，使用下述命令处理采样文件，得到优化指导文件（`.profdata`）：
+
+    ```shell
+    $LLVM_DIR/bin/llvm-profdata merge -output=foo.profdata ./*.profraw   #$LLVM_DIR表示编译器路径
+    ```
+
+4. 增加选项 `-fprofile-use=$PROFILE_DATA_PATH/foo.profdata` 编译源码得到优化后的可执行文件。
+
+## 注意事项
+
+1. 插桩之后的运行阶段，程序需要正常结束才能正常生成采样文件，直接 `kill -9` 不能正常生成采样文件。
+
+2. 如果程序无法正常退出，可以尝试以下方法生成 profile。（以 MySQL 为例）
+
+    ```shell
+    echo "set height 0" > gdb.cmd
+    echo "handle SIGPIPE SIGUSR1 SIGUSR2 SIG36 noprint nostop" >> gdb.cmd
+    echo "call (void)__llvm_profile_write_file()" >> gdb.cmd
+    echo "detach" >> gdb.cmd
+    echo "q" >> gdb.cmd
+    gdb -x gdb.cmd -p `pidof mysql` # mysql 对应具体采样进程
+    ```
+
+3. 在[使用方法](#使用方法)步骤 3 中 merge profile 时，如果出现 `counter overflow` 的错误提示，可以通过增加环境变量 `LLVM_PROFILE_FILE=$PROFILE_DATA_PATH/code-%p`，按照每个进程生成采样文件，减少进程间耦合导致采样异常的问题。
diff --git a/docs/zh/server/development/llvm/more_architecture_supported.md b/docs/zh/server/development/llvm/more_architecture_supported.md
new file mode 100644
index 0000000000000000000000000000000000000000..72b2a09fd53839cba4ae67c469087a83088c0bb2
--- /dev/null
+++ b/docs/zh/server/development/llvm/more_architecture_supported.md
@@ -0,0 +1,10 @@
+# 新增架构支持
+
+LLVM for openEuler 支持通过 `-mcpu=` 选项指定当前的 cpu 型号，使能该 cpu 所有默认特性。在使能对应的微架构亲和选项后，LLVM for openEuler 会依据对应架构的指令实现进行指令流水线调优，提升性能。硬件平台与该选项的配置项对应关系如下：
+
+|硬件平台|配置项|
+|-|-|
+|鲲鹏920|tsv110|
+|HiSilicon Hip09|hip09|
+|HiSilicon Hip10c|hip10c|
+|HiSilicon Hip11|hip11|
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-caution.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-caution.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-caution.gif differ
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-danger.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-danger.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-danger.gif differ
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-note.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-note.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-note.gif differ
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-notice.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-notice.gif
new file mode 100644
index 0000000000000000000000000000000000000000..86024f61b691400bea99e5b1f506d9d9aef36e27
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-notice.gif differ
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-tip.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-tip.gif
new file mode 100644
index 0000000000000000000000000000000000000000..93aa72053b510e456b149f36a0972703ea9999b7
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-tip.gif differ
diff --git a/docs/zh/server/development/llvm/public_sys-resources/icon-warning.gif b/docs/zh/server/development/llvm/public_sys-resources/icon-warning.gif
new file mode 100644
index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571
Binary files /dev/null and b/docs/zh/server/development/llvm/public_sys-resources/icon-warning.gif differ