https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64536
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 34404 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34404&action=edit gcc5-pr64536.patch Given that tidy_fallthru_edge seems to be called only rarely, I think adding too much code to handle tablejumps with single successor is not a good idea. So I think we should just give up on tablejumps there. And perhaps make sure we optimize single successor tablejumps somewhere else, where it is run often enough that it will be actually beneficial. E.g. int a; #define A(n) case n: a++; break; #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) \ A(n##5) A(n##6) A(n##7) A(n##8) A(n##9) #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) \ B(n##5) B(n##6) B(n##7) B(n##8) B(n##9) void foo (int x) { switch (x) { C(1) } } on x86_64 with -O2 or -O2 -fpic isn't optimized, because tidy_fallthru_edges isn't called and so we do not even attempt to do anything about it. On the s390x testcase it is called just because some other cleanup in another part of the function created unreachable blocks that need cleanup. And, wonder why tree-ssa-tail-merge.c doesn't want to optimize this. Perhaps it gives up because of the load and store?
