https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #14 from Roger Sayle <roger at nextmovesoftware dot com> --- This really is a regression, that points to a previously latent/unnoticed bug in combine. In GCC 12, combine would take the input RTL and based on target costs transform it into the better of implementation A or B. Now in GCC 13, the tree-optimizers are able to perform this same optimization earlier and so combine is now given optimal implementation A, where a latent bug always transforms this to B without ever checking target costs. The consensus is that performing (more) optimizations at the tree-level is a good thing, so reverting changes to the tree optimizers (that now produce better code) is a workaround to a glitch where combine is transforming RTL into more expensive forms. There's already a code path in combine that checks/compares costs, it just isn't being reached any more. p.s. this has nothing to do with sign_extract/zero_extract, for which hardware support would be hypothetical, this patch only affects sign_extend/zero_extend, such as aarch64's sxtw or x86_64's movsx or powerpc's extsw. If a target has this functionality, it's unlikely that a sequence of shifts or bit-wise operations would be better.
