== 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.