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.