In AArch64, some of the integer operations support “w” constraint (FP_REGS). For example *addsi3_aarch64 pattern supports it. However, not all of the integer operations supports it. In the cases where it is supported, all the operands have to be in FP_REGS and it will not work if we have one operand in FP_REGS and other in GENERAL_REGS.
If there is an allocno whose pseudo register is used only in *addsi3_aarch64 insns, it will have low cost for register class FP_REGS (as in the case of a28 below exacted from an example). If the other pseudo register used in *addsi3_aarch64 (a27 in the example below) is also used in instructions (rorsi3_insn in the exaple below) that does not support “w” constraint, there is going to be a cost involved in moving it from FP_REGS to GENERAL_REGS (or other way)
[Andrew] I bet if *aarch64_ashl_sisd_or_int_<mode>3 had ! on those constraints it would be much better and work correctly.
Thanks for that. That is precisely what I am planning on investigating.
Currently IRA dosent seems to be considering this dependency in considering this inter dependency in cost calculation.
[Andrew] Yes because the back-end does not tell IRA anything about the constraints. It is not a limitation in IRA/LRA but rather how *aarch64_ashl_sisd_or_int_<mode>3 says it can pick any of those alternatives equally. See https://gcc.gnu.org/onlinedocs/gccint/Multi-Alternative.html#Multi-Alternati...
If this is not a limitation on the part of the IRA and can be managed by adjusting the cost for constraints, it will definitely save lot of time. I saw one of your old patch for enabling "?" in IRA (I cant find the link now). Is that problem fixed now ?
Thanks, Kugan