This is somewhat related to the following RFC by @rjmccall:
C 18.104.22.168p7 (N1548) says:A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned) for the referenced type, the behavior is undefined.
C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms
of conversions from void*:An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(static_cast<cv void*>(v)).
C++ [expr.static.cast]p13 says of conversions from void*:A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T” .... If the original pointer value represents the address A of a byte in memory and A satisfies the alignment requirement of T, then the resulting pointer value represents the same address as the original pointer value, that is, A. The result of any other such pointer conversion is unspecified.
Currently clang does not optimize based on the fact that the pointers
passed into the function must be appropriately aligned for their pointee type.
We now have a motivation to change that. Namely, it was estabilished that
not doing so prevents LICM, and it is likely not the only penalized transform.
Now, somehow i don't think we can just start optimizing on that.
Let's first give users tools to weed out the cases where the pointer
passed into function's argument is underaligned.
I've yet to actually see just how much mayhem this causes,
at least on the LLVM stage-2 build.