This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]