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

[Jessica Clarke via Phabricator via llvm-commits]

jrtc27 added a comment.

In D108961#2980097 <https://reviews.llvm.org/D108961#2980097>, @kito-cheng wrote:

>>> So when we need this magic?
>>>
>>> 1. GCC didn't have integrated assembler like LLVM, so instruction length for inline asm can only use a very roughly way to estimate.
>>
>> Is that not a problem for every architecture though?
>
> Yeah, but RISC-V is more frequently hit due to shorter range for conditional branch, I believe integrated assembler is right way to resolve this, but sadly it's not existing in GCC :(

I don't particularly like adding magic to RISC-V just because it hits an issue shared by many architectures more often than them. If I can break every architecture other than RISC-V with a sufficiently-large blob of inline assembly then it seems to me like GCC needs fixing, not that RISC-V should have a special hacky workaround just for it that gets exposed to and relied upon by users?

>>> 2. Mostly this is used for hand-written assembly file, RISC-V conditional branch only provide very short range compare to other RISC ISA; +-32K for MIPS, +-32M for ARM32, +-32K(TBZ/TBNZ) ~ +-1M(CBZ/CBNZ) for AArch64, but only +-2K for RISC-V, that made RISC-V is more easy to hit out-of-range condition branch issue, of cause we can ask programmer to convert this by themselves, but out-of-range error is reported until linker time because RISC-V has relaxation, that made many user confuse, (relocation truncate to fit???), this magic can prevent that confusion in most case.
>>
>> There's nothing stopping an assembler from detecting that a label will/won't/might be out of range for a given branch by doing best-case and worst-case analysis on the instruction sequence and emitting an error in the case where it's definitely going to be out of bounds however much you relax, and a warning when it's unsure because it depends on how much relaxation there is (which is likely to be relatively rare, normally these cases are _way_ out of bounds for user-provided assembly).
>
> Technically that's feasible solution, but I think that's would be more like philosophical issue here :p




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108961