On Wed, Jan 13, 2016 at 11:06 AM, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > > 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.
I think the only way forward is to make PROMOTE_MODE and promote_function_mode agree. I hope nobody else is going to ack hacks here and there (esp. with "I think it cannot happen" comments...). Oh, and document that they have to agree. Richard. > 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 >> >
