efriedma added a comment. Not sure what sort of test would catch this; it's not crashing, and the types with the tail padding issue are not naturally exposed by target intrinsic headers (so it would only show up for code using ext_vector_type, or maybe OpenCL code). I only tripped over the issue by inspection.
The way LLVM currently works, vectors never have internal padding, only tail padding. (This could possibly change in the future, I guess, but there aren't any specific plans.) For the types clang can generate, tail padding can show up a few different ways: 1. A vector can have an element count that's not a power of two: <5 x double> 2. A vector can partially cover a byte: <4 x i1> 3. A vector can have an element type that naturally has padding, like x86 long double I can write testcases for the above, if you would find it helpful. (Actually figuring out how to pad a vector correctly is more work than I really want to invest into this right now. In the tricky cases, it might make sense to convert the constant to an integer, and pad that.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76528/new/ https://reviews.llvm.org/D76528 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
