The motivation for the current design (requiring the result and the operand to have the same mode) was from PR middle-end/50161. The challenge there is that when the RTL optimizers can determine that the operand is a constant, simplify_rtx sees just a CONST_INT with VOIDmode and therefore doesn't know what the original/intended mode of the operation is/should be.
Using patterns with explicit truncates, sign or zero extensions avoids these problems, but still allows backend insns where the result mode differs from the operand mode. > On 1 Jan 2023, at 21:03, Segher Boessenkool <seg...@kernel.crashing.org> > wrote: > On Sun, Jan 01, 2023 at 03:55:26PM -0000, Roger Sayle wrote: >> In 2011, the rtl.texi documentation was updated to reflect that the >> modes of the RTX unary operations FFS, POPCOUNT and PARITY must >> match those of their operands. > > Is that not a limitation we should try to get rid of? It does not > really make any sense after all. > >> Unfortunately, some of the transformations >> in simplify-rtx.cc predate this tightening of RTL semantics, and have >> not (until now) been updated/fixed. i.e. The POPCOUNT and PARITY >> optimizations were "correct" when I originally added them back in 2007. > > What would be needed to fix this the "other" way? Just update the > documentation? Or is there some code that requires this strange > constraint, maybe even some checking thing? > > If we *do* want this strange limitation, we really should have some RTL > check that enforces it, makes sure we find it if the rules are broken. > > Segher
