[llvm] [ExpandMemCmp] Only narrow load sizes for targets that opt in (PR #215186)

[Pengcheng Wang via llvm-commits]

wangpc-pp wrote:

> Why this fix rather than adjusting the BPF values for `NumLoadsPerBlock` (up to 8, i guess?), and maybe also `MaxLoadsPerMemcmp` (it's less clear what this should be scaled by, but maybe it should be 1/8 of what it was?)

`NumLoadsPerBlock` only affects the `zero-cmp` path — ordering `memcmp` still emits one block per load, so the 33-branch blowup stays. `MaxLoadsPerMemcmp` gates how big a compare to inline, not the load width, and shrinking it would also stop inlining cheap wide-load compares. For BPF, the actual thing that broke is that load width got forced to i8.

> Is BPF correctly reporting how it supports (or not) misaligned accesses?

I think it is a YES. It correctly reports "misaligned load/store is not allowed" as `AllowsMisalignedMemAccess` defaults false.
https://github.com/llvm/llvm-project/blob/524e20d6c6559de7fef8953cea543c0023a39f6b/llvm/lib/Target/BPF/BPFSubtarget.cpp#L72
The bug is that the filter treats that as "wide load is bad" — but BPF backend legalizes a wide unaligned load into a branchless byte sequence (load i64, align 1 → 8 byte-loads, 0 branches). IIUC, the report is right.

> Do we maybe need different filtering/costing for trying to understand how many loads a misaligned load/store will be split into, and scaling things with that?

This regression is because of the branch explosion, not the number of split instruction count (the split is branchless for BPF backend). We fix the regression quickly with the opt-in flag, which has already been reviewed in the previous design. The right long-term direction may be adding a hook to model how an unaligned load/store is split in the backend.

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