== Progress ==
- Travelling from TCWG sprint (2/10)
- Zero/sign extension elimination (TCWG-291) 2/10 * Posted the modified patch and some discussions. Further testing.
-SHA1 regression (TCWG-468) 4/10 * Looked at IRA's uses of back end cost model. It might be a limitation (See the notes below). Looking at the test-case from sha1 which also has inline asm whose constraints are causing further issues.
- Misc (2/10) * Looked at bugs assigned (https://bugs.linaro.org/show_bug.cgi?id=85) * Set-up LLVM
== Plan == - Sha1 regressions - Fixing assigned Bugs
--------------------------------------------------------------------- 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)
Currently IRA dosent seems to be considering this dependency in considering this inter dependency in cost calculation.
See below.
Thanks, Andrew
-----Original Message----- From: linaro-toolchain-bounces@lists.linaro.org [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Kugan Sent: Monday, August 4, 2014 12:19 AM To: Linaro Toolchain Subject: [ACTIVITY] 28 July - 1 August 2014
== Progress ==
- Travelling from TCWG sprint (2/10)
- Zero/sign extension elimination (TCWG-291) 2/10 * Posted the modified patch and some discussions. Further testing.
-SHA1 regression (TCWG-468) 4/10 * Looked at IRA's uses of back end cost model. It might be a limitation (See the notes below). Looking at the test-case from sha1 which also has inline asm whose constraints are causing further issues.
- Misc (2/10) * Looked at bugs assigned (https://bugs.linaro.org/show_bug.cgi?id=85) * Set-up LLVM
== Plan == - Sha1 regressions - Fixing assigned Bugs
--------------------------------------------------------------------- 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.
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...
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
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
See below.
-----Original Message----- From: Kugan [mailto:kugan.vivekanandarajah@linaro.org] Sent: Monday, August 4, 2014 12:50 AM To: Pinski, Andrew; Linaro Toolchain Subject: Re: [ACTIVITY] 28 July - 1 August 2014
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.
[Andrew] I have a similar patch already in locally and it gives a small performance improvement on a benchmark on Cavium's processor; at least in 4.9, I have not looked into the code generation in later versions just yet.
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-Alt ernative
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 ?
[Andrew] Actually it was for '!': https://gcc.gnu.org/ml/gcc-patches/2008-10/msg01323.html . It never went in but I think other things have changed since then as I said I used '!' on *aarch64_ashl_sisd_or_int_<mode>3 and it gave me the behavior I wanted.
Thanks, Kugan
linaro-toolchain@lists.linaro.org
-
Kugan -
Pinski, Andrew