https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
