https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82668
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Not sure where we would have the necessary infrastructure for this.
To be able to use rorx instead of the right shift, the requirement is that the
only use (or all uses) of the shift destination are ignoring the upper bits,
i.e. only use lowpart SImode of it. But combine apparently can't help here,
I see only:
Failed to match this instruction:
(parallel [
(set (reg:SI 91)
(plus:SI (subreg:SI (zero_extract:DI (reg/v:DI 90 [ s ])
(const_int 32 [0x20])
(const_int 32 [0x20])) 0)
(subreg:SI (reg/v:DI 90 [ s ]) 0)))
(clobber (reg:CC 17 flags))
])
Failed to match this instruction:
(set (reg:SI 91)
(plus:SI (subreg:SI (zero_extract:DI (reg/v:DI 90 [ s ])
(const_int 32 [0x20])
(const_int 32 [0x20])) 0)
(subreg:SI (reg/v:DI 90 [ s ]) 0)))
Failed to match this instruction:
(set (reg:SI 91)
(plus:SI (subreg:SI (lshiftrt:DI (reg/v:DI 90 [ s ])
(const_int 32 [0x20])) 0)
(subreg:SI (reg/v:DI 90 [ s ]) 0)))
Having a myriad of SImode arithmetics define_insn_and_split that would match
one of the operands to be a subreg of lshiftrt or zero_extract is not
maintainable.
Or very specialized peephole2 that would handle this.
Or handle it at expansion time, though the problem is that the extvdi/extzvdi
patterns are expected to extract DImode value from DImode source, not SImode
from DImode source, and rorx $32 obviously doesn't provide that.
