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.
