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