jfb added a comment. In D57898#1395953 <https://reviews.llvm.org/D57898#1395953>, @glider wrote:
> ... which happily skips the padding. I don't think padding is an issue right now. It's valid to either initialize it or not. It is slightly unfortunate to lose the information about padding (which the struct approach keeps). One alternative could be to store a struct when it has padding (i.e. not two stores of char+int, but a single store struct of char+int). From what I've seen the optimization pipeline doesn't do as well with that type of stores. You might instead just choose to not do anything in this patch if the struct has padding. We can do something later. FWIW I intend to write a separate patch which lets you opt in to padding always being set. I'll be touching this code anyways. > It occurs to me that we need to properly handle the padding in `patternFor` > before we'll be able to split the structures. patternFor handles padding already: it treats it as any value, and chooses something adjacent. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57898/new/ https://reviews.llvm.org/D57898 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
