[lld] [lld][ARM] Don't emit veneers for wraparound branches. (PR #165263)

[Simon Tatham via llvm-commits]

statham-arm wrote:

> I've put what I've found in the various Arm ARMs. From what I've been able to find it seems fine, apart from v8-A and above, where I think it is UNKNOWN (and hence can't be relied on). This could just be my reading of the Arm ARM though as the UNKNOWN parts may not be related to branch instructions.

Hmmm, you had a completely different methodology from me in checking the Arm ARM. I didn't try to find any high-level text about address space wraparound in general. I made a beeline for the architecture pseudocode of the BL instruction and checked the semantics specified in that.

Armv8-A Arm ARM (ARM DDI 0487 version L.a): the pseudocode for the BL instruction in §F.5.1.25 creates the offset `imm32` by calling `SignExtend(..., 32)` with the first parameter being a pile of bits from the instruction encoding, and then makes the target address as either `PC32 + imm32` or `Align(PC32, 4) + imm32`.

The semantics of the `+` operator are defined in §K.16.4.4.2, and vary with the data type – there's provision made for `bits(N)` bitstring types, and actual integers, and a combination of both. In the case where both inputs are `bits(N)` for the same `N`, the definition is the obvious one: addition is mod 2^N, so that wraparound has the obvious behaviour. So we only need to check that the two operands to `+` in the target address calculation are `bits(32)` and not some other type.

The `SignExtend` pseudocode function, creating the offset `imm32`, returns the type `bits(N)` where `N` is the second parameter. So that's `bits(32)`. The `PC32` pseudo-variable is also defined as having type `bits(32)`. And the `Align` pseudocode function can take an integer or a bitstring, and returns the same type.

So I think that a formal interpretation of the pseudocode says that wraparound is supposed to work, and the same is true for the `B` instruction (§F5.1.18) as well as `BL`.

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