| # Adding a New BOLT Backend |
| |
| A new BOLT backend should follow LLVM's |
| [policy for adding a new target](https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target). |
| New BOLT targets are experimental and are not built by default. |
| |
| Most target-specific work should be isolated in an `MCPlusBuilder` |
| implementation under `bolt/lib/Target/<Target>`, together with |
| platform-specific relocation handling in `bolt/lib/Core/Relocation.cpp`. |
| |
| Changes to common infrastructure, particularly `MCPlusBuilder`, must be |
| separate from the target changes and land first. Such changes require thorough |
| tests and must state their processing-time and peak-memory impact on existing |
| targets. Measurements should use large binaries, including at least Clang |
| itself. |
| |
| A backend does not need to implement every `MCPlusBuilder` interface initially. |
| However, omitted interfaces must be checked against their callers. Analyses and |
| passes that depend on missing functionality, such as stack frame analysis or |
| register liveness, must remain disabled. |
| |
| BOLT passes are not cleanly partitioned into common and target-specific code. |
| Enable them for a new target only after auditing their target assumptions and |
| proving them stable with target-specific and end-to-end tests. Otherwise, keep |
| them disabled. |
| |
| RISC targets generally need the `LongJmp` pass for branch relaxation. This |
| requires correct branch-range checks and short- and long-jump construction, |
| with tests covering range boundaries, calls, tail calls, and linker relaxation. |
| |
| The initial backend should include focused tests for instruction analysis, |
| relocations, CFG construction, rewriting, and each enabled pass. Validation |
| must include rewriting and executing large real-world binaries, with Clang as |
| the minimum large-binary test. |
