https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #15 from cqwrteur <unlvsur at live dot com> --- (In reply to rguent...@suse.de from comment #14) > On Mon, 19 Jul 2021, unlvsur at live dot com wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 > > > > --- Comment #13 from cqwrteur <unlvsur at live dot com> --- > > (In reply to Richard Biener from comment #12) > > > (In reply to Richard Biener from comment #11) > > > > With some hand-waving we could generate > > > > > > > > void square(unsigned t, int *tt) > > > > { > > > > if (t<=4) __builtin_abort(); > > > > tt[0] = 0; > > > > tt[1] = 0; > > > > tt[2] = 0; > > > > tt[3] = 0; > > > > tt[4] = 0; > > > > } > > > > > > > > but I don't see how it fits any existing transform? The "hand-waving" > > > > would be that __builtin_abort () since it's a known function cannot > > > > observe the dropped side-effects like tt[0] = 0 when t > 0. > > > > > > That is, we'd sink the stores across the abort ()s because they are > > > not uses of them, then we arrive at > > > > > > if (t<=0) __builtin_abort(); > > > if (t<=1) __builtin_abort(); > > > if (t<=2) __builtin_abort(); > > > if (t<=3) __builtin_abort(); > > > if (t<=4) __builtin_abort(); > > > tt[0] = 0; > > > tt[1] = 0; > > > tt[2] = 0; > > > tt[3] = 0; > > > tt[4] = 0; > > > > > > where we'd somehow "thread" to a single condition (PRE tail merging > > > merges the abort () blocks and reassoc way after it manages to merge > > > the controlling conditions). > > > > https://godbolt.org/z/af8nn8K4h > > > > I found this to be interesting. with -fno-exceptions, all those calls are > > folded together. It looks -fno-exceptions hurts optimizations here. Is that > > a > > bug or C++ EH truly affects the semantics here? > > It's likely not "semantics" but the pass responsible likey simply gives > up on incoming EH edges. There's some long-term TODO to base that > off some more modern tooling. I do not see anything wrong to assume the semantics of __builtin_trap() and __builtin_abort() for compiler. Just like we treat memcpy or __builtin_memcpy or memmove as some kind of magic intrinsic in the compiler. Even memcpy maybe implemented by libc differently. So this optimization is technically valid.
