On 01/13/2016 03:06 AM, Kyrill Tkachov 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'd lean that way as well, but will defer to those more knowledgeable
about the ARM world than myself if they want to go a different direction.
jeff
