This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64
- From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 26 Aug 2016 19:33:02 +0000
- Subject: [Bug target/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64
- Auto-submitted: auto-generated
- References: <bug-77289-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
Thank you for working on this PR.
> Adding Vlad since there are IRA and LRA questions.
>
>
>
> I'm not sure if IRA is supposed to always assign operand 1 the same register
> as operand 0 here, or whether that is reload/LRA's job. Vlad?
>
Yes, satisfying all constraints is major goal of reload/LRA.
>
> Vlad, should we be disallowing matching of eliminable registers here or just
> special ones like stack pointers and maybe others? If so, I guess we could
> add a strict param to get_hard_regno() and get_final_hard_regno() that
> doesn't allow eliminable registers by not calling
> lra_get_elimination_hard_regno() when strict. Thoughts?
I think we should ignore elimination here (in operand matching). The final
elimination is not guaranteed. We will create additional reloads (reg moves)
in case of ignoring elimination but they will be removed if the elimination
really happens.
Peter, please go ahead and try this approach. If it works I'll approve the
patch.