https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #28 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #27)
> Let me decrypt how clang generates the red zones. I can probably quickly
> come up with a patch that will do the dynamic red zone size allocation.
> Having that you'll be able to rebuild kernel and catch remaining issues.
So the functions looks as follows:
static size_t VarAndRedzoneSize(size_t Size, size_t Granularity,
size_t Alignment) {
size_t Res = 0;
if (Size <= 4) Res = 16;
else if (Size <= 16) Res = 32;
else if (Size <= 128) Res = Size + 32;
else if (Size <= 512) Res = Size + 64;
else if (Size <= 4096) Res = Size + 128;
else Res = Size + 256;
return alignTo(std::max(Res, 2 * Granularity), Alignment);
}
It's bit confusing as it's size of variable plus red zone in shadow memory. So
to calculate just the size of redzone one has to subtract Size. And there's
some rounding up according to alignment.
I've prepared table with size of variable and corresponding middle end red zone
size:
+---------------+-----+------+---------+
| Variable size | GCC | LLVM | ratio |
+---------------+-----+------+---------+
| 1 | 63 | 15 | 23.81% |
| 4 | 60 | 12 | 20.00% |
| 8 | 56 | 24 | 42.86% |
| 12 | 52 | 20 | 38.46% |
| 16 | 48 | 16 | 33.33% |
| 32 | 32 | 32 | 100.00% |
| 40 | 56 | 40 | 71.43% |
| 50 | 46 | 46 | 100.00% |
| 64 | 32 | 32 | 100.00% |
| 96 | 32 | 32 | 100.00% |
| 128 | 32 | 32 | 100.00% |
| 129 | 63 | 79 | 125.40% |
| 196 | 60 | 76 | 126.67% |
| 256 | 32 | 64 | 200.00% |
| 257 | 63 | 79 | 125.40% |
| 511 | 33 | 65 | 196.97% |
| 512 | 32 | 64 | 200.00% |
| 1024 | 32 | 128 | 400.00% |
| 1025 | 63 | 143 | 226.98% |
| 2048 | 32 | 128 | 400.00% |
| 4096 | 32 | 128 | 400.00% |
| 8192 | 32 | 256 | 800.00% |
+---------------+-----+------+---------+
As seen (and mentioned by you), for small variables we have bigger red zones.
