ARM CodeGen issue

[mcourteaux]

On arm-32-linux, correctness/fuzz_extract_lanes revealed:

Original expr: interleave_vectors(x6((int64)3), min(select(select(ramp(int64(p0), (int64)12, 6) > x6(int64(p2)), ramp(int64(p0), (int64)12, 6), x6((int64)8)) > (x6((int64)6) + x6((int64)10)), select(ramp(int64(p0), (int64)12, 6) > x6(int64(p2)), ramp(int64(p0), (int64)12, 6), x6((int64)8)), ramp((int64)14, (int64)12, 6) - x6(int64(p1))), int64x6((uint64x6)absd(concat_vectors(ramp(int64(p1), (int64)8, 3), ramp((int64)11, (int64)3, 3)), min(ramp((int64)14, (int64)12, 6), ramp((int64)0, (int64)15, 6))))))
Original type: int64x12
Variables: p0=14
p1=4
p2=10
Original values: -8589934592 0 34359738368 0 647672684611436344 153839768 0 1970324836974592 4294967295 661625229473037816 65536 -8589934592
Failed with seed 5792148528566212763

Whereas the correct "original values" should have been (extracted from running this on x86):

Original values: 3 4 3 3 3 10 3 34 3 46 3 57

I have not narrowed this further down than this. It seems the ARM codegen is in pretty bad shape whenever we try to do anything custom, instead of just handing it over to LLVM.

[alexreinking]

Really looks like an invalid sign extension issue

[abadams]

ARM is the oldest Halide backend continuously used in production. SVE2 is not in good shape, and our ARM bots just started testing with SVE2.... I wonder if we've actually lost test coverage. The x86 bots make sure to test older x86 targets too, but I'm not sure the ARM bots are testing with and without SVE2.

[mcourteaux]

Well, this particular test failed on ARM-32, without SVE2 I'm assuming. https://github.com/halide/Halide/actions/runs/23111542219/job/67129763852?pr=8629

[abadams]

Honestly that's the backend least likely to be broken. Maybe I messed up something in the test itself...

[abadams]

Though using int64s on a 32-bit target is not something that is going to show up in production imaging pipelines.

[abadams]

It's not easy to figure this one out. I propose skipping this test in your PR on everything except for a single reliable target (e.g. x86-64-linux), so that it's just testing the IR transformation, not various LLVM backends too. Then we can do #9044 and reintroduce testing of LLVM's vector code generation.