| Issue |
143908
|
| Summary |
excessive stack usage with -fsanitze=kernel-address
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
arndb
|
While going through the remaining cases of excessive stack usage with ASAN and MSAN
that I hit with the Linux kernel, I came across one that was particularly surprising in how
it uses multiple kilobytes of stack with clang but not with gcc.
I have reduced it to a test case that uses 760 bytes with clang, but grows if similar code
is added into the inner loop:
```
enum omap_plane_id {
OMAP_DSS_GFX, OMAP_DSS_VIDEO1, OMAP_DSS_VIDEO2, OMAP_DSS_VIDEO3, OMAP_DSS_WB,
};
static inline unsigned short DISPC_OVL_BASE(enum omap_plane_id plane)
{
switch (plane) {
case OMAP_DSS_GFX: return 0x0080;
case OMAP_DSS_VIDEO1: return 0x00BC;
case OMAP_DSS_VIDEO2: return 0x014C;
case OMAP_DSS_VIDEO3: return 0x0300;
case OMAP_DSS_WB: return 0x0500;
default: return 0;
}
}
struct dispc_device {
unsigned ctx[0x4000];
};
void dispc_write_reg(unsigned idx, unsigned val);
void dispc_runtime_resume(struct dispc_device *dispc, int has_feature)
{
for (int i = 0; i < 5; i++) {
for (int j = 0; j < 8; j++) {
unsigned short tmp = DISPC_OVL_BASE(i);
dispc_write_reg(0, dispc->ctx[tmp + j]);
}
for (int j = 0; j < 8; j++) {
unsigned short tmp = DISPC_OVL_BASE(i) + 0x800;
dispc_write_reg(0, dispc->ctx[tmp + j]);
}
}
}
```
For a reproducer, please see https://godbolt.org/z/1E55chKa3. From what I can
tell, all the loops are unrolled here, the calculation of each unrolled 'tmp + j' gets
inexplicably moved to the beginning of the loop and then spilled to the stack.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
