[Bug rtl-optimization/100328] IRA doesn't model dup num constraint well

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Created attachment 50715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50715&action=edit
ira:consider matching cstr in all alternatives

With little understanding on ira, I am not quite sure this patch is on the
reasonable direction. It aims to check the matching constraint in all
alternatives, if there is one alternative with matching constraint and matches
the current preferred regclass, it will record the output operand number and
further create one copy for it. Normally it can get the priority against
shuffle copies and the matching constraint will get satisfied with higher
possibility, reload doesn't create extra copies to meet the matching constraint
or the desirable register class when it has to.

For FMA A,B,C,D, I think ideally copies A/B, A/C, A/D can firstly stay as
shuffle copies, and later any of A,B,C,D gets assigned by one hardware register
which is a VSX register but not a FP register, which means it has to pay costs
once we can NOT go with VSX alternatives, so at that time we can increase the
freq for the remaining copies related to this, once the matching constraint
gets satisfied further, there aren't any extra costs to pay. This idea seems a
bit complicated in the current framework, so the proposed patch aggressively
emphasizes the matching constraint at the time of creating copies.

FWIW bootstrapped/regtested on powerpc64le-linux-gnu P9. The evaluation with
Power9 SPEC2017 all run shows 505.mcf_r +2.98%, 508.namd_r +3.37%, 519.lbm_r
+2.51%, no remarkable degradation is observed.