| Issue |
122571
|
| Summary |
Backend crashes on a store to a large vector
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
npanchen
|
I'm investigating issue we have that is similar to https://github.com/llvm/llvm-project/issues/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:
```c
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 ?
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
