Division operation much slower with microlib than other libs on cortex-M0

[LMESTM]

Description of defect

Following investigations in #12116 , it turns out that division with microlib seems much slower than ARM lib (and possibly also other libs) on cores like cortex-M0.

Few measurement on a "divided by 1000" operation were measured and are reported here for background information:

Board	Toolchain	Division	Operation time (incl. IOs toggling)	Frequency during wake-up
L476RG	uARM	Native ( / )	440ns	48MHz
L476RG	uARM	Div1000	480ns	48MHz
L476RG	ARMC6	Native ( / )	440ns	48MHz
L476RG	ARMC6	Div1000	480ns	48MHz
L073RZ	uARM	Native ( / )	86µs	4MHz
L073RZ	uARM	Div1000	226µs	4MHz
L073RZ	uARM	Div10 (3 times)	18µs	4MHz
L073RZ	ARMC6	Native ( / )	11,6µs	4MHz
L073RZ	ARMC6	Div1000	13µs	4MHz
L073RZ	ARMC6	Div10 (3 times)	18µs	4MHz

Target(s) affected by this defect ?

ALL

Toolchain(s) (name and version) displaying this defect ?

microlib toolchain (µARM)

What version of Mbed-os are you using (tag or sha) ?

mbed-os master of Jan 2020.

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Not relevant here.

How is this defect reproduced ?

See detailed history in #12116

[0xc0170]

What would be suggestion here? From the link in the #12116, this loos like it should be known issue with microlib.

It might be worth reaching out internal team who is in charge for microlib ?

[kjbracey]

For division, microlib is doing what's being advertised, which is being smaller and slower. And I'm inclined to think the trade-off is okay. It's 40 bytes instead of 340 bytes. 8 times slower (in this case), 8 times smaller. 8 times slower isn't enough to be that much of a problem, except when running at like 4MHz.

I'm more concerned about the 64-bit multiply (which the div1000 was using there). That is tens of times slower, AND many times bigger. It would be better in all regards to just use the standard library routine. We should raise this with the tools team.

That only seems to be a problem for M0/M0+/M23 - the microlib library routine for M3 is also catastrophically slow, but the compiler seems to not use it - it just inlines optimal code instead.

In the interim, we could paste in the standard library routines with #if MICROLIB somewhere - that should override the currently-poor microlib definitions.

[MarceloSalazar]

Note we're waiting from Arm to comment and confirm how to proceed.

[MarceloSalazar]

Note this affects all Cortex-M0/M0+.
@kjbracey-arm can you please review?

[MarceloSalazar]

@kjbracey-arm any update on this?

[evedon]

This issue seems to also affect cortex M4 (STM32F303 for example). See #12880

[kjbracey]

A fix for this is now expected in a future ARM Compiler 6 update.

Current expectation is that future microlib will have the same smaller+faster 64-bit multiply as the standard library. No Mbed OS change required there.

It will default to the the current division operations, but the faster+bigger versions from the standard library will be selectable by an IMPORT directive, which we'll have to add. That in turn could be put under a Mbed config option. So there will need to be a PR for that when the toolchain is available.