On 13/01/16 06:59, Jim Wilson wrote:
On Tue, Jan 12, 2016 at 5:40 PM, Jim Wilson <jim.wil...@linaro.org> wrote:The info is in here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 See the comments on gcc.target/arm/wmul-[123].c which no longer generate smulbb etc instructions, which are 16x16=32 expanding multiplies which are faster on some older parts that have them. They are present in armv5e and higher architecture versions.I forgot about the ldrub/ldrsb problem. ldrub is preferred, particularly for older targets, e.g. thumb1, as it accepts more addressing modes than ldrsb.
Well, Thumb1 is used in armv6-m i.e. for currently used microcontrollers where codesize is important, so we should gather data on how much this actually hurts us there. Building some popular embedded benchmarks for Thumb1 with various optimisation levels (including -Os!) with and without the change in option 1 is something we should do.
We can't get ldrub if PROMOTE_MODE doesn't do unsigned extension. So we have a number of bad choices here 1) We can remove sign-changing promotions from PROMOTE_MODE, and accept slower code for pre-thumb2 architectures.
I personally think this is the most promising way forward, as long as we fully understand the effect on codegen and work towards minimising any negative effects. Thanks, Kyrill
2) We can add sign-changing promotions to function_promote_mode, and accept a minor ABI change. 3) We can add strange and probably fragile extensions to the middle end to work around the ARM back end problem. 4) We can just leave the ARM port broken and let it occasionally generate incorrect code. Option 4 is the one that we've been using for the last 8 months or so. I think we should do either 1 or 2, though that depends on what the ARM maintainers are willing to accept. Jim
