[llvm] [AArch64] Don't try to vectorize fixed point to fp narrowing conversion (PR #130665)

[David Green via llvm-commits]

davemgreen wrote:

> I did notice that arguably turning off vectorization of this operation might be the most efficient way. It does leave the loop rather than unrolling it, but the code is quite a bit tighter and the scalar conversion is precise.

Yeah - we should probably try to address both. There are two issues going on - no matter where the vector i64->f32 convert comes from (vectorization, intrinsics, optimizations, the front end) we should be producing correctly rounded code (*). This patch is the bug fix for that issue. Then there is the question of whether the vectorizer should be producing the vector operations. That will probably require a cost-model change to increase the costs (which might mean they are still used in loops with other vector operations, they will just be scalarized for that portion, it still might be profitable overall).

(* I was wondering if there was something that we could do with fast-math to make this OK. Especially as AFAICT it has been this way for 10+ years without anyone having an issue so far. None of the existing flags match exactly, but maybe contract or afn could be co-opted into it. (If fptrunc+fptrunc could be contracted, maybe fptrunc can be "uncontracted" into fptrunc+fptrunc). Something for a follow-on if we need it maybe, we might be able to use SVE instructions instead for some of them if the architecture feature is present).

If you can update all the failing test cases we can take a look at whether they need to change. I believe, for example, that i32->half conversions are always fine (https://alive2.llvm.org/ce/z/RXvYNv). That probably applies to higher int sizes too as the range or a half is relatively narrow. BFloats I would guess the same as float, unfortunately, but it would be good if we could prove one was right or wrong.

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