Backend crashes on a store to a large vector

[npanchen]

I'm investigating issue we have that is similar to #93391. From my understanding, the #93391 was closed assuming it's impossible to write C/C++ code that generates provided code as frontend will catch and report that large type.
However, our case is possible to reproduce using vector type that Clang and GCC support:

typedef int vtype __attribute__ ((vector_size (262144)));

void zero(vtype *x) {
  *x = *x ^ *x;
}

% clang -c test.c -O1 
Assertion failed: (SDNode::getMaxNumOperands() >= Vals.size() && "too many operands to fit into SDNode"), function createOperands, file SelectionDAG.cpp, line 13500

The IR is quite trivial:

define void @zero(ptr initializes((0, 262144)) %x) {
entry:
  store <65536 x i32> zeroinitializer, ptr %x, align 16
  ret void
}

C code can be compiled by GCC without any problems.

So the questions is: should backend correctly handle large vector sizes or it's assumed to be unsupported by LLVM in general, therefore vector with #elements > 65535 are disallowed ?

[topperc]

gcc seems to have turned that into a memset of 0. If I change the xor to an add, gcc times out on godbolt.

We can raise the limit in the backend, but I suspect it would lead to long compile times for large vectors.

[npanchen]

gcc seems to have turned that into a memset of 0. If I change the xor to an add, gcc times out on godbolt.

Yeah, gcc generates better code in this case. However, not sure if such large vectors are used in real world. That said, it might be ok for now to have non-memset generated by LLVM.

We can raise the limit in the backend, but I suspect it would lead to long compile times for large vectors.

#122737
I think long compile time is fine as long same test can be compiled with Clang and GCC.
What seems to be not fine is compile time difference between Clang and GCC of the same test:

typedef int vtype __attribute__ ((vector_size (262144)));

void square(vtype *x) {
  *x = *x + *x; // <<< not xor
}

$ time gcc -c test.c -S 

real    0m12.582s
user    0m12.349s
sys     0m0.231s

$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

$ time clang -c test.c -S 

real    0m41.482s
user    0m41.379s
sys     0m0.100s

$ clang --version
Ubuntu clang version 18.1.8 (++20240731024944+3b5b5c1ec4a3-1~exp1~20240731145000.144)

generated code seems identical.

[npanchen]

Assuming that CodeGen changes are fine, it does look like the limit needs to be documented in

• Clang for vector_size that supports 2^31
• LangRef for vector type as right now AsmPrinter allows vector's size is 2^32-1, which is different to Clang's limit

anything else ?