[llvm] Validate immediates for SCVTF, UCVTF and EXT (PR #214233)

[Zane Hambly via llvm-commits]

Zaneham wrote:

The `ext` change looks right to me. I'd arrived at the same one independently before I spotted this PR, down to `imm32_0_7` and `imm32_0_15`.

One thing that might be worth adding to the tests. The missing constraint didn't only affect symbols, it silently truncated out-of-range literals too. Before this patch:

```
ext v0.8b,  v1.8b,  v2.8b,  #12   encoding: [0x20,0x20,0x02,0x2e]
ext v0.8b,  v1.8b,  v2.8b,  #4    encoding: [0x20,0x20,0x02,0x2e]
ext v0.16b, v1.16b, v2.16b, #20   encoding: [0x20,0x20,0x02,0x6e]
ext v0.16b, v1.16b, v2.16b, #4    encoding: [0x20,0x20,0x02,0x6e]
```

Index 12 assembles as index 4 on the 64-bit form because the class forces `imm{3}` to 0, and 20 becomes 4 on the 128-bit form. Your patch fixes that as well, it just isn't covered, and it's the case most likely to regress quietly since it needs no symbols to reproduce.

Something like this next to the symbol cases would catch it:

```
        ext v0.8b, v1.8b, v2.8b, #8
// CHECK-ERROR: [[@LINE-1]]:34: error: immediate must be an integer in range [0, 7].
        ext v0.16b, v1.16b, v2.16b, #16
// CHECK-ERROR: [[@LINE-1]]:37: error: immediate must be an integer in range [0, 15].
```

And the valid extremes would pin the ranges down, since `neon-extract.s` currently only tests `#0x3` for both forms:

```
        ext v0.8b, v1.8b, v2.8b, #7
        ext v0.16b, v1.16b, v2.16b, #15
```

Also a heads up in case it saves someone review time, #213490 covers the `scvtf`/`ucvtf` half too.


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