https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #41 from Alexander Klepikov <klepikov.alex+bugs at gmail dot com> --- > > It looks like with optimization enabled it converts bitwise AND to right > > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be > > optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll > > cannot be converted. It seems that very first optimization spoils things. > > > > But when we have numerous 'shar' instructions, optimization joins the game > > again and converts them to 'tst'. > > Yes, something like this is what I remember happening there. I'll try to > look into the issue with your test cases and see if it's possible to add > some patterns to catch those. Thank you! I have an idea. If it's impossible to defer initial optimization, maybe it's possible to emit some intermediate insn and catch it and optimize later? > BTW, have you tried it on a more recent GCC? There have also been some > optimizations in the middle-end (a bit more backend independent) for this > kind of thing. I tried 13.1 about week or two ago with the same result. > Have you tried to use whole program optimization via -flto and > -ffunction-sections? It should be able to strip out all unnecessary library > functions. Thank you for advice, I'll take a try.
