[lld] [RISCV][lld] Guarding lld relaxation for RISCV (PR #130265)

Craig Topper via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 7 10:08:08 PST 2025


topperc wrote:

> It feels like a part of the address assignment loop where every pass is correct to emit (differing only in performance), should intrinsically never produce a failure to converge. That feels like something that should be part of the contract between the loop and the various targets.

The algorithm has a flaw that causes it to oscillate in some cases. We're looping between 2 or 3 different states. We need to account for the maximum alignment of all sections between the call instruction section and the call target section when relaxing calls and jumps. When one sections shrinks the start addresses of the sections after it may move by less than the number of bytes removed due to alignment requirements. This non-linear movement confuses the algorithm. The maximum alignment is not readily available and looping over the sections to compute it on the fly may be expensive.

I've been told that binutils linker hit the same issue in the past. I know they check the maximum alignment and I was told there is a maximum number of passes.

> 
> More specifically, it seems rough to have the target deciding which pass number to quit on; this would go out of sync if we lower or raise the pass limit in the address assignment loop. It seems cleaner to have it communicate something like: "from here on in, every pass is optional". (In this case, every pass might be optional?)

I think we don't want RISC-V relaxation to ever fail so we should probably remove the convergence failure check from the caller for RISC-V relaxation and let RISC-V choose when to give up.

https://github.com/llvm/llvm-project/pull/130265


More information about the llvm-commits mailing list