[PATCH] D108961: [RISCV] MC relaxation for out-of-range conditional branch.

Thu Sep 2 06:58:02 PDT 2021

jrtc27 added a comment.

In D108961#2979562 <https://reviews.llvm.org/D108961#2979562>, @asb wrote:

> In D108961#2973678 <https://reviews.llvm.org/D108961#2973678>, @jrtc27 wrote:
>
>> I know GNU as does this but I don't see why that's a good idea nor why we should; if you use a conditional branch to a label that's too far away then that's your problem and you should have written non-broken code. Having it insert the long branch form is too much magic for me...
>
> Yes, I'm in two minds about this. I'm usually in favour of trying to match GNU tools behaviour in order to minimise porting issues / provide a more predictable user experience. But fighting against that, I'm really not a fan of these "magic" transformations either.
>
> The fear with adding anything like this is of course adding a very rarely executed path that ends up having bugs in obscure cases. As such, if we were to go in this direction I'd be keen to see more extensive test coverage.

FWIW, I *think* the origin of this stems from:

(a) GCC/binutils divide
(b) GCC uses pseudos in its output (even uses li in some cases, though often mixed in with other shifts and adds for decomposing immediates, bit odd)
(c) GCC has limited knowledge of compression

so GCC doesn't actually know how far away things are and thus can't pick the right branch all the time. Fixing it up in the assembler was presumably the easier solution rather than fixing GCC to emit correct assembly. That then has the unfortunate effect of becoming something hand-written assembly relies on (e.g. bbl was, as was FreeBSD in one place very early on before LLVM was mature enough to build it).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108961/new/

https://reviews.llvm.org/D108961