https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #42 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Alexander Klepikov from comment #41) > > 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? This is basically what is supposed to be happening there already. However, it's a bit of a dilemma. 1) If we don't have a dynamic shift insn and we smash the constant shift into individual stitching shifts early, it might open some new optimization opportunities, e.g. by sharing intermediate shift results. Not sure though if that actually happens in practice though. 2) Whether to use the dynamic shift insn or emit a function call or use stitching shifts sequence, it all has an impact on register allocation and other instruction use. This can be problematic during the course of RTL optimization passes. 3) Even if we have a dynamic shift, sometimes it's more beneficial to emit a shorter stitching shift sequence. Which one is better depends on the surrounding code. I don't think there is anything good there to make the proper choice. Some other shift related PRs: PR 54089, PR 65317, PR 67691, PR 67869, PR 52628, PR 58017 > > 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. > Good to know. Thanks for checking it!
