{ld,st}.w can handle any alignment (with a performance penalty). I guess the compiler sees the 16-bit-ness of the load and uses the appropriate {ld,st}.[su]h instructions. Fair enough choice really but annoying that it explodes in this way..

so ... the byte pointed at by lr is loaded into r9, then, the halfword pointed at by lr+1 is loaded into r5.
It seems the variable pointed at by lr (char*?) is correctly aligned, but contains binary data that needs to be parsed - bitmap, probably. And, using this code, this will never succeed in a machine that forces alignment.

On the other hand, the compiler should never have generated code that acesses an aligned variable+1 as a word, should it?

Grr, now I see what you meant ... looking into the source code ... someone tried to optimise in a way that uses an explicitly unaligned access.