[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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.