https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> 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.
x86 has ix86_secondary_reload that should handle this situation.
