As per #142559, this marks ftrunc as legal for Neon and upgrades the existing
arm.neon.vrintz intrinsics.

Follow-up to #141333. Relocation generation called both addReloc and
applyFixup, with the default addReloc invoking shouldForceRelocation,
resulting in three virtual calls. This approach was also inflexible, as
targets needing additional data required extending
`shouldForceRelocation` (see #73721, resolved by #141311).

This change integrates relocation handling into applyFixup, eliminating
two virtual calls. The prior default addReloc is renamed to
maybeAddReloc. Targets overriding addReloc now call their customized
addReloc implementation.

As per #142559, this marks fceil as legal for Neon and upgrades the existing
arm.neon.vrintp intrinsics.

To prevent people from modernizing the loop, add a comment that
fixupImmediateBr can append to ImmBranches.

... due to their close relationship. MCSection's inline functions (e.g.
iterator) access MCFragment, and we want MCFragment's inline functions
to access MCSection similarly (#146307).

Pull Request: https://github.com/llvm/llvm-project/pull/146315

As per #142559, this marks fround as legal for Neon and upgrades the existing
arm.neon.vrinta intrinsics.

to not expose SmallVector to the callers. We will make fixup storage out
of line.

Revoke the change in https://github.com/llvm/llvm-project/pull/146198

This marks ffloor as legal providing that armv8 and neon is present (or
fullfp16 for the fp16 instructions). The existing arm_neon_vrintm
intrinsics are auto-upgraded to llvm.floor.

If this is OK I will update the other vrint intrinsics.