@usr: Presently, given void foo(int32_t x); int i; int16_t a[256]; ... a[i]++; foo(a[i]); optimal code for something like an ARM7-TDMI would be ldrb r0,[r1+r2] / add r0,#1 / strb r0,[r1+r2] / asl r0,r0,#16 / asr r0,r0,#16 / bl _foo. The fourth and fifth instructions essentially perform temp = (signed)((unsigned)temp<<16)>>16 (the fastest way to convert int32_t to int16_t on that CPU). If a were declared oint16_t which behaved as I described, it shouldn't be hard...

...for a compiler to figure out that there wasn't any need to coerce the value computed for a[i] into the range of an int16_t before passing it to foo. A savings of two instruction words and two cycles, with behavior that is consistent with a simple-to-understand execution model. Another thing to note about such types is that they would reduce the need for many kinds of optimization. Given int16_t x=0; for (i=0; i<n; i++) x+=i; foo(x); a compiler could easily interpret x as...

...a uint32_t register within the loop and delay the coercion to int16_t until the call to foo, so the runtime cost of the coercion would only be incurred once rather than n times, but such optimizations take work. If x were type oint16_t, the compiler could simply omit the coercion altogether and not have to rely upon the optimizer to minimize the cost thereof.

BTW, I wonder to what extent anyone has attempted to come up with any "normative" execution models? I don't think the language should attempt to say that there's only one "normative" model, since different applications would benefit from different execution models (e.g. there are some situations where it would be acceptable for an application to crash when given invalid inputs, but it would be unacceptable to have it yield bogus results; ...

...there are other situations where crashing is unacceptable, but almost any output would be acceptable when given invalid input). There can be advantages to writing code in such a way that it will be usable even on systems that deterministically trap certain forms of UB even in cases that would otherwise be benign, but there can also be advantages to being able to avoid checks whose sole purpose is to avoid forms of UB whose natural consequences would be benign if ignored by the compiler...

...such as aliasing violations in situations where a program's behavioral requirements would be met under a model where reading a pointer of type T may arbitrarily yield the last value which has been written as any particular type since the last value was written as type T or a char type.

In some cases, a having build which could trap on many aliasing violations could be useful when trying to debug code which was not relying upon the aforementioned execution model, but in cases where it could be shown that any behavior consistent with the above model would meet requirements, adding conditional logic to prevent what would otherwise have been harmless memory accesses may make the code slower and harder to read.