Inconsistent optimization remarks from rustc

[yugr]

I'm trying to get optimization remarks about loop vectorization.

This code

#[no_mangle]
pub fn foo(v: &[i32], n: usize) -> i32 {
    let mut ans = 0;
    for i in 0..n {
        ans += v[i];
    }
    ans
}

is clearly vectorized by rustc:

$ RUSTFLAGS='--crate-type=rlib -O -C target-cpu=native'
$ rustc $RUSTFLAGS test.rs
$ objdump -d libtest.rlib
...
  50:   c5 fd fe 04 87          vpaddd (%rdi,%rax,4),%ymm0,%ymm0
  55:   c5 f5 fe 4c 87 20       vpaddd 0x20(%rdi,%rax,4),%ymm1,%ymm1
  5b:   c5 ed fe 54 87 40       vpaddd 0x40(%rdi,%rax,4),%ymm2,%ymm2
  61:   c5 e5 fe 5c 87 60       vpaddd 0x60(%rdi,%rax,4),%ymm3,%ymm3
  67:   48 83 c0 20             add    $0x20,%rax
  6b:   48 39 c1                cmp    %rax,%rcx
  6e:   75 e0                   jne    50 <foo+0x50>

Now I try to get optimization remark about this from compiler. I try two approaches: dedicated option

$ rustc $RUSTFLAGS -C debuginfo=1 -C remark=all test.rs &> remarks.txt

# A lot of remarks
$ wc -l remarks.txt
150 remarks.txt

# But NOTHING about vectorization
$ grep -i vector remarks.txt || echo 'No matches'
No matches

and passing arguments directly to LLVM:

# Only one remark is produced and that about vectorization !
$ rustc $RUSTFLAGS -C debuginfo=1 -C 'llvm-args=--pass-remarks=.*' test.rs
remark: /rustc/6ccd4476036edfce364e6271f9e190ec7a2a1ff5/library/core/src/iter/range.rs:764:12: vectorized loop (vectorization width: 8, interleaved count: 4)

I think there are several bugs here:

1. -Cllvm-args=--pass-remarks=.* and -Cremark=all produce different result (currently the former gives a lot of remarks but omits vectorizer and the latter reports a single remark from vectorizer)
2. -Cremark=all does not report remark from vectorizer
3. -Cremark=loop-vectorize does not report anything at all
4. -Cllvm-args=--pass-remarks=.* reports remarks only for vectorizer

Tested for

$ rustc +stable --version
rustc 1.87.0 (17067e9ac 2025-05-09)
$ rustc +nightly --version
rustc 1.89.0-nightly (6ccd44760 2025-06-08)

This was originally reported in comments here.