[Bug sanitizer/81387] UBSAN consumes too much memory at -O2

2017-07-17 Thread jakub at gcc dot gnu.org
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

2017-07-17 Thread rguenth at gcc dot gnu.org
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

2017-07-11 Thread babokin at gmail dot com
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

2017-07-11 Thread marxin at gcc dot gnu.org
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

2017-07-11 Thread jakub at gcc dot gnu.org
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.