critical sections: remove unnecessary volatile

[kjbracey]

Description

Critical section count/state variables are synchronised by IRQ disabling and
critical section calls themselves, so do not need to be volatile.

This eliminates a couple of unnecessary reads of the counter variable.

Saves a few bytes of ROM, and a bit of time in speed-critical code.

Pull request type

[ ] Fix
[X] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@scartmell-arm, @c1728p9

[ciarmcom]

@kjbracey-arm, thank you for your changes.
@c1728p9 @scartmell-arm @ARMmbed/mbed-os-core @ARMmbed/mbed-os-hal @ARMmbed/mbed-os-maintainers please review.

[pan-]

Good change, it would be interesting to have a mention about volatile uses in the handbook at some point.

Funnily enough that change doesn't change code generated: https://godbolt.org/z/za4blY

[kjbracey]

hal_critical_section_exit loses 2 load instructions: https://godbolt.org/z/IOL0lW (although 1 load could have already been saved by proper use of -- operator, and other load should probably be an assert anyway).

The other file is just being done for consistency, and doesn't gain anything because it accesses each variable only once per function.

I'm looking through a few other bits of code - getting paranoid about LTO.

[pan-]

It would be interesting to add the -Wodr warning to LTO gcc's config. In my experience, most of the issues I have faced with LTO were related to ODR violation and these may be hard to find.

[kjbracey]

My latest bit of paranoia is implementations of hal_critical_section that don't use PRIMASK, eg nRF52. If they're just doing a memory-mapped write to NVIC, that does have a built-in CPU barrier, but not the compiler barrier you get from the PRIMASK intrinsic or assembler... Do our current compilers reorder normal memory accesses across volatile accesses?

(Without LTO, function calls to other compilation units are compiler barriers, which does a lot of lifting. LTO loses that).

[kjbracey]

Do our current compilers reorder normal memory accesses across volatile accesses?

Immediate answer from an old GCC manual:

Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory.

[pan-]

@kjbracey-arm https://bugs.launchpad.net/gcc-arm-embedded/+bug/1722849?comments=all and https://gcc.gnu.org/ml/gcc-help/2017-10/msg00061.html might worth the read.

[kjbracey]

Interesting link. asm volatile presumably should force ordering with respect to other volatiles, like C volatile accesses, and that's been fixed. It's not enough though - for a critical section, you still need a memory clobber to act as compiler barrier against the normal code inside, and I see current CMSIS has that.

Raised a CMSIS issue here about NVIC_EnableIRQ lacking a barrier: ARM-software/CMSIS_5#493

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 7 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-GCC_ARM

[0xc0170]

We are experiencing CI node failures, few jobs were aborted. We are investigating, will restart the jobs once fixed.

cc @ARMmbed/mbed-os-test

[NirSonnenschein]

re-running to check if CI issue is resolved

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts