Hi! On Fri, Jun 19, 2020 at 09:42:54PM +0100, Roger Sayle wrote: > My recent patch to add scalar integer simplification unit tests to > simplify_rtx_c_tests > identified two "trivial" corner cases that could be improved in > simplify-rtx.c.
These two things are independent changes and should be independent patches. > Although it makes no sense to ever see a BImode ROTATE, the current ordering > of transformations in simplify_binary_operation_1 converts (rotate:bi > (reg:bi) 0) to > (rotatert:bi (reg:bi) 1), which then doesn't get simplified away. Rather > than teach > the middle-end that any hypothetical ROTATE or ROTATERT of a BImode value is a > no-op, a more realistic invariant is that any rotate by const0_rtx is already > canonical. I don't know of a rotate of BImode is defined at all, but that is beside the point, the patch has nothing to do with BImode. A rotate by constant 0 should be simplified to just its argument, and that should happen *before* where your patch makes changes. What goes wrong there? > Optimizing "parity of parity" matches the tree constant folding > transformation pending > review. Alas, the only mentions of PARITY in GCC's official backend machine > descriptions > are in expanders, so the middle-end's RTL optimizers never see a PARITY to > simplify. This part is approved for trunk. Thanks! > A test can be added to test_scalar_int_ops once that patch is > reviewed/approved. If you insist. I find this futile busy-work, now and in the future :-/ Segher
