何时被编译成二进制

不同 OpenCL 实现策略不一：有的实现（eager）在 clBuildProgram 就把 SPIR‑V/源编译成设备可执行的“最终二进制”；有的实现（lazy）把最后与 kernel 名/链接相关的工作延迟到 clCreateKernel（或更晚的 enqueue）才完成。POCL、Intel/AMD 驱动、以及你当前仓库里都可能采用不同策略——没有单一“标准”。具体说明（举例与原理）

1 eager（尽早编译）¶

行为：clBuildProgram 在构建时尽可能把 program 编译成目标设备的本机代码 / 设备二进制，并把结果保存在 program 的 binary 中（或每个 kernel 的 binary）。
优点：clCreateKernel/clEnqueue 的延迟更小，运行时启动快（第一次运行之前的开销已完成）；便于把最终二进制写入缓存供后续进程/会话直接加载。
缺点：如果用户只创建 program 不马上用到某个 kernel，会做无用工作；对不同设备/驱动版本更脆弱（缓存失效风险）。
代表：很多 CPU-target 的实现（如 pocl 在 CPU 后端的某些配置）会在 build 时把 LLVM IR 或 native code 生成出来；但具体行为依实现与目标不同。

2 lazy（延迟到 clCreateKernel/运行时）¶

行为：clBuildProgram 完成前端/中间表示（例如从 SPIR‑V 生成内部 VIR 或 IL），但不完成 kernel 名相关的最终链接/打包；当 clCreateKernel 指定 kernel 名时，驱动用已有的 VIR/IL 做 kernel 层的 load/link/最终化，生成可运行的二进制。
优点：只为实际使用的 kernel 做最终编译/打包，节约不必要工作；更容易把某些需要 kernel-name 的转换（例如把 main 插入）放在知道 kernel 名的时刻
缺点：首次 clCreateKernel/首次运行会有较高延迟。你仓库的实现：正是 lazy 风格——clBuildProgram 会把 SPIR‑V → VIR（并设置 binarySize），但 clfLoadAndLinkVIRShader（在 clCreateKernel 内）才会基于 kernel name 调用 vscLoadKernel/vscLinkKernel 等生成最终可执行表示（见仓库 vscLoadKernel / vscSaveShaderToBinary 等 API 的存在与调用点

3 POCL 的做法（补充背景，避免绝对化）¶

pocl 的不同后端策略不同：对于 CPU 后端，pocl 常在 clBuildProgram 阶段把 program 转换为 LLVM IR 并生成目标本地代码（因为 CPU 后端能在构建期就生成并复用 native code）；对于较异构/需要设备专属后端的情况，pocl 也可能延迟一些后端工作到 kernel 创建或运行时。总结：pocl 并不是统一把最终设备二进制放在 clBuildProgram——实现会根据后端能力做权衡。在你当前仓库里如果要把“最终二进制”提前到 clBuildProgram，需要考虑的实现细节

4 是否能获取 kernel 名单？¶

很多后端在真正 final 化/链接时需要 kernel 名（用于生成 main、入口点等）。如果想在 clBuildProgram 生成所有 kernel 的最终 binary，必须先枚举或推断所有 entry points（从 SPIR‑V/IL 反射出入口点列表）。否则只能针对已知名字逐个生成。