https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #19 from thopre01 at gcc dot gnu.org --- Yeah, when doing something like (((((x[0] << 8) | x[1]) << 8) | x[2]) << 8) | x[3] there is already a depth proportional to the size of the value being byte swapped with a coefficient due to casting. But I need to evaluate the impact of increasing the limit in terms of compilation time. If the impact is noticeable, it might be necessary to do the refactoring suggested by Richard Biener in [1] first. [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00616.html "From the performance side the pass could be re-structured to populate a lattice, thus work from def to use instead of the other way around. Which means we visit each stmt exactly once, compute its value symbolically and check it against a rotate."
