Security principles for TrustZone for ARMv8-M - example slide 22

Thanks Diya. I agree ! I would however change the wording a little bit. An optimizing compiler TYPICALLY would try to do one load and cache values in registers(assuming we did not declare *s as volatile). So rather than saying s_saved would be optimized away because *s is not marked volatile, and because a compiler prefers to do loads instead of caching it in a register sounds weird. The problem really is that the compiler may not be able to optimize that statement to do one load into a register and use the register later, as one would intuitively expect, when there is register contention, as pointed out in the link above.
Anyway, it appears that this problem can be extrapolated to secure code performing memcpy's from non secure to secure memory! if the non secure memory pointer is not marked as volatile, the memcpy might be optimized away.

Thanks Diya. I agree ! I would however change the wording a little bit. An optimizing compiler TYPICALLY would try to do one load and cache values in registers(assuming we did not declare *s as volatile). So rather than saying s_saved would be optimized away because *s is not marked volatile, and because a compiler prefers to do loads instead of caching it in a register sounds weird. The problem really is that the compiler may not be able to optimize that statement to do one load into a register and use the register later, as one would intuitively expect, when there is register contention, as pointed out in the link above.
Anyway, it appears that this problem can be extrapolated to secure code performing memcpy's from non secure to secure memory! if the non secure memory pointer is not marked as volatile, the memcpy might be optimized away.