https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-03-01
Ever confirmed|0 |1
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have:
(insn 8 6 9 2 (set (reg:TI 93 [ *_2 ])
(mem:TI (zero_extend:DI (reg:SI 91)) [1 *_2+0 S16 A64])) "pr79571.c":8
80 {*movti_internal}
(expr_list:REG_DEAD (reg:SI 91)
(expr_list:REG_EQUIV (mem/c:TI (symbol_ref:DI ("a") [flags 0x2]
<var_decl 0x7f40f2f19e10 a>) [1 a+0 S16 A64])
(nil))))
and the constraints/predicates are:
(define_insn "*movti_internal"
[(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,v,v ,v ,m")
(match_operand:TI 1 "general_operand" "riFo,re,C,BC,vm,v"))]
The (zero_extend:DI (reg:SI 91)) is valid address for nonimmediate_operand or m
constraint, but not for o constraint, as it is not offsetable. I'd have
expected LRA to force the zero_extend into some DImode register and that would
then be offsetable. Or does the backend need to use a predicate like e.g.
rs6000
offsettable_mem_operand (in this case like nonimmediate_operand, but if it is a
MEM, fail if not offsetable)? That would in general pessimize the case where
the source is in a vector register.
