We can't just combine patch_aarch64_21r and patch_aarch64_12 into one relaxed relocation without a deeper understanding of the control flow, unfortunately. The issue is that the code can can jump into the middle of the two instructions involved in the relocation, and the combined relaxation changes the meaning of that.
This happens with _IS_NONE on debug 3.13 builds for AArch64 Linux, so it's a legitimate concern. We just dodged the bullet because _IS_NONE is never actually emitted (we turn it into a guard).
I think the best course of action is to remove the patch_aarch64_33rx from 3.13, 3.14, and main. Something like this probably belongs in the textual assembly optimization pass, since we actually reason about control flow there.
I'll open the PRs to remove the bug first. If somebody (perhaps from Arm @diegorusso @markshannon?) can prove this relaxation is valuable and wants to add it back on main in that earlier pass, then feel free to do so.
Linked PRs
We can't just combine
patch_aarch64_21randpatch_aarch64_12into one relaxed relocation without a deeper understanding of the control flow, unfortunately. The issue is that the code can can jump into the middle of the two instructions involved in the relocation, and the combined relaxation changes the meaning of that.This happens with
_IS_NONEon debug 3.13 builds for AArch64 Linux, so it's a legitimate concern. We just dodged the bullet because_IS_NONEis never actually emitted (we turn it into a guard).I think the best course of action is to remove the
patch_aarch64_33rxfrom3.13,3.14, andmain. Something like this probably belongs in the textual assembly optimization pass, since we actually reason about control flow there.I'll open the PRs to remove the bug first. If somebody (perhaps from Arm @diegorusso @markshannon?) can prove this relaxation is valuable and wants to add it back on
mainin that earlier pass, then feel free to do so.Linked PRs