excessive stack usage with -fsanitze=kernel-address

[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.