[Bug sanitizer/81387] UBSAN consumes too much memory at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387 --- Comment #5 from Jakub Jelinek --- Maybe we should just disable the REE pass if we can predict from number of basic blocks, their sizes or number of edges that DF_UD_CHAIN + DF_DU_CHAIN computation will be really expensive.
[Bug sanitizer/81387] UBSAN consumes too much memory at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387 --- Comment #4 from Richard Biener --- There's a dup of this specific issue (workaround: -fno-ree), can't find it right now.
[Bug sanitizer/81387] UBSAN consumes too much memory at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387 --- Comment #3 from Dmitry Babokin --- Interesting that you've mentioned -fno-sanitize-recover, I haven't realized that it has effect on the number of basic blocks. But by default I run "-fsanitize=undefined -fno-sanitize-recover=undefined", so the numbers that I posted are for this combination (-fno-sanitize-recover=all is effectively the same). I've tried without -fno-sanitize-recover=undefined and it is: -O2 -fsanitize=undefined: 358s, 62Gb -O1 -fsanitize=undefined: 280s, 2.7Gb Also clang trunk: -O2 -fsanitize=undefined: 173s, 1.5Gb -O2 -fsanitize=undefined -fno-sanitize-recover=undefined: 224s, 1.8Gb I understand that the reasons for consuming more memory with UBSAN enabled are quite fundamental, but looking at such an extreme increase may uncover problems when algorithms consume more that they supposed to. Again, I'm not insisting on fixing it, I'm rather drawing attention to suspicious behaviour, which you may consider worth looking at.
[Bug sanitizer/81387] UBSAN consumes too much memory at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387 --- Comment #2 from Martin Liška --- Just for curiosity, I tried to use clang++ 4.0.0 and clang++ pr81387.ii -c -O2 -fsanitize=undefined took me about 180s and memory was ~2.5GB.
[Bug sanitizer/81387] UBSAN consumes too much memory at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387 --- Comment #1 from Jakub Jelinek --- I'm afraid it is unfixable, if you want smaller memory consumption, you either need smaller routines, or use -fno-sanitize-recover=all, or do multiple builds with selected subsets of -fsanitize=undefined, so that you don't have that many checks in one function, or use -O1 on the larger functions to avoid many optimizations that are e.g. quadratic in the number of basic blocks. The UBSAN checks are many and especially if they are recoverable, they increase the number of basic blocks way too much.