> > --------------------------------------------------------------------- > 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-Alternative > > 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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
