<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 18, 2020, 12:54 AM David Rector <<a href="mailto:davrecthreads@gmail.com">davrecthreads@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div style="margin:0px;font-stretch:normal;line-height:normal">I would have to think that, whatever the documentation for  e.g. <span style="font-stretch:normal;line-height:normal;font-family:Menlo">getTypeAlignInChars(T)</span>, most users expect it to return T’s actual alignment for their target, whether it was determined from the ABI, or the AIX alignment scheme, or whatever.<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There really are two concepts at play here.</div><div dir="auto"><br></div><div dir="auto">1. Given a pointer to some object of type T or a field of type T inside another object, what can I know for sure about the alignment of that pointer? (How many of the low bits are absolutely guaranteed to be 0, assuming the program doesn't involve Undefined Behavior?)</div><div dir="auto"><br></div><div dir="auto">2. If I want to allocate a brand new complete object of type T, at what alignment should I use to place it? This must be at least the alignment from 1. But beyond that, it could differ by circumstance, e.g. stack, global, and function parameter allocations could make different choices. In some cases, increasing the alignment of an allocation above the required minimum may just be an optimization, but in other cases it has an ABI impact.</div><div dir="auto"><br></div><div dir="auto">AIX is not the first platform where these alignments differ -- the type 'double' on x86-32 being the other notable example. But, the AIX rules trigger differences in more circumstances than we've had before, and thus we now need to potentially make a choice in other parts of the code. Importantly: in AIX rules, an aggregate can now have a different preferred alignment from guaranteed alignment, too.</div><div dir="auto"><br></div><div dir="auto">The first case brought up where this surely matters, is 'new T[100]' where T has a destructor. This thread is exploring whether there are other such cases that we might need to change, too. I suspect that there are not many, but that remains to be determined.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">In fact, maybe we can go further: I would think that any valid use of type alignment which explicitly ignores AIX or other target-specific alignment schemes are probably just implementation details used only in the calculation of some composed type’s alignment under that scheme.  In other words I would assume every function call in which AIX preferred alignment needed to be ignored is in the some layout-building implementation — is that right?</div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">E.g. the lib/AST/RecordLayoutBuilder.cpp example you cite below fits this description — in <span style="font-stretch:normal;line-height:normal;font-family:Menlo">LayoutField(FieldDecl *D, …)</span> you propose to change the call to fetch the ABI/non-AIX type info via </div><div style="margin:0px;font-stretch:normal;line-height:normal"><font face="Menlo">getTypeInfo(D->getType(), true/* NeedsABIAlignment */);</font></div><div style="margin:0px;font-stretch:normal;line-height:normal">but only so that you can later tweak that info whenever <span style="font-stretch:normal;line-height:normal;font-family:Menlo;color:rgb(27,31,34);background-color:rgb(255,255,255)">DefaultsToAIXPowerAlignment==true</span>. </div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">If all the changes you would need to make are indeed similar to this, these expanded usages are really only implementation details needed to build type layouts, and thus the goal should simply be to sufficiently hide these details from common programmers who don’t need to build type layouts, only access them.</div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">I think your original option #2 ("add a flag"), i.e. adding new defaulted parameters to a few functions, seems to be a reasonable way to hide these new details, so long as the new parameters are well named and documented.  It also seems sufficiently general to be useful for implementing other special default alignment schemes in the future.</div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">Dave</div></div><br></div></blockquote></div></div></div>