https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I gave up on fixing the problem in LRA. Taking operand and insn
predicates into account is a wrong approach. It results in many new
test failures. As an example, for insn with operand 1 equivalent to a
constant
(define_insn "vec_dup<mode>"
[(set (match_operand:AVX_VEC_DUP_MODE 0 "register_operand" "=x,x,x,v,x")
(vec_duplicate:AVX_VEC_DUP_MODE
(match_operand:<ssescalarmode> 1 "nonimmediate_operand"
"m,m,x,v,?x")))]
We can not insert equiv according to the operand predicate. This
means that the constant will be put into memory (on the stack) and the
memory will be used in vec_dup insn.
As for now LRA/reload ignores the operand predicate, LRA inserts the
constant in vec_dup insn. And to satisfy the operand constraints, LRA
just put the constant into the constant memory pool. So ignoring the
operand predicates results in at least one less insn generation.
Following only operand constraints in LRA/reload is more flexible
approach and results in generation of better code in the most cases.
So now I believe that the PR should be fixed in machine-dependent code.
I am attaching such candidate patch solving the PR. I hope that target
maintainers could use it as a starting point for solving the PR.
