Instead of depending on implicit padding from the structure layout code, use a packed struct and emit the padding explicitly.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/GlobalMerge.cpp | ||
---|---|---|
464 | The eliminated check below used DL.getPreferredAlignment. Is this equivalent? If I understand getPointerAlignment correctly, it is more conservative than DL.getPreferredAlignment. So it seems the eliminated check was too conservative. It eliminated things that might not have had a problematic alignment. Just making sure I'm understanding this correctly. |
lib/CodeGen/GlobalMerge.cpp | ||
---|---|---|
464 | For a global with a strong definition, getPointerAlignment() is basically something like GVar->getAlignment() == 0 ? DL.getPreferredAlignment(GVar) : GVar->getAlignment(). That isn't exactly consistent with what the backend would do; getGVAlignmentLog2 seems to do something more like std::max(DL.getPreferredAlignment(GVar), GVar->getAlignment()). This doesn't really matter because getPreferredAlignment itself returns GVar->getAlignment() for globals with explicit alignment... unless the explicit alignment of the global is less than the ABI alignment of the global's type, in which case the alignment is forced to the ABI alignment of the type. But this result is ignored by getGVAlignmentLog2 if the global has a section marking, in favor of the explicit alignment. (This was introduced in r129428/r129432 for reasons I don't really understand.) So it's a mess, but getPointerAlignment() should return the same result except for the weird edge case involving an explicitly under-aligned global. |
lib/CodeGen/GlobalMerge.cpp | ||
---|---|---|
464 | Ok, and for that weird edge case it would force an alignment greater than the explicit alignment. That seems fine given the other benefits of this change. Thanks! |
Use DataLayout::getPreferredAlignment so we end up with the same alignment the AsmPrinter would have computed. Not sure if the AsmPrinter is actually behaving the way we want it to, but we should consider that separately.
The eliminated check below used DL.getPreferredAlignment. Is this equivalent? If I understand getPointerAlignment correctly, it is more conservative than DL.getPreferredAlignment. So it seems the eliminated check was too conservative. It eliminated things that might not have had a problematic alignment.
Just making sure I'm understanding this correctly.