<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2020, at 9:26 AM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 19, 2020 at 8:53 PM David Rector <<a href="mailto:davrecthreads@gmail.com" class="">davrecthreads@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div style="margin:0px;font-stretch:normal;line-height:normal" class="">For that matter "preferred alignment" is also confusing.  Who prefers it?  When might that preference not be met?</div><div style="margin:0px;font-stretch:normal;line-height:normal;min-height:14px" class=""><br class=""></div><div style="margin:0px;font-stretch:normal;line-height:normal" class="">Here is my full understanding so far, expressed in the hope that pointing out my confusions here might better help answer Xiangling’s questions below:</div>
<ul class="">
<li style="margin:0px;font-stretch:normal;line-height:normal" class=""> The "ABI" alignment of a type = the ABI-guaranteed minimum alignment of any object of that type built by any standard-conformant compiler.</li></ul></div></blockquote><div class="">Correct, this is the guaranteed alignment of any(***) object of that type (either top-level complete object or a subobject).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><ul class="">
<li style="margin:0px;font-stretch:normal;line-height:normal" class="">The "preferred" alignment of a type = the actual alignment, at least as large as the ABI alignment, that <i class="">our</i> compiler will <i class="">always</i> use in constructing an object of that type.</li></ul></div></blockquote><div class="">When constructing a global or local variable, yes, we do. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><ul class=""><li style="margin:0px;font-stretch:normal;line-height:normal" class="">Therefore, whenever we are dealing with an object we know <i class="">our</i> compiler has constructed, we can use the "preferred" alignment.</li><ul class=""><li style="margin:0px;font-stretch:normal;line-height:normal" class="">And thereby take advantage of target-specific optimizations like AIX.</li></ul>
<li style="margin:0px;font-stretch:normal;line-height:normal" class="">However, whenever we are dealing with e.g. a pointer to an object we are not sure we built — i.e. which may have been constructed within a function not compiled by our compiler (e.g. a function compiled without AIX in some library might have constructed that object and passed a pointer to it to some function our compiler is presently building) -- we are forced to use only the ABI-guaranteed minimum alignment.</li><ul class=""><li style="margin:0px;font-stretch:normal;line-height:normal" class="">`-And thereby miss out on AIX.</li></ul></ul></div></blockquote><div class="">The most critical difference isn't really our compiler vs someone else's compiler. The "preferred" alignment is actually part of the ABI, too (yet another reason why "ABI alignment" is an awful name, and "guaranteed alignment" is better).</div><div class=""><br class=""></div><div class="">The preferred alignment applies only to creation of a full object, not, for example, to fields within a struct. E.g. on x86-32:</div><div class="">   struct Foo { int i; double d; }; </div><div class="">the double is placed at offset 4 within the struct, not 8. So, on x86-32, when we have a pointer than could be pointing to such an object, we must only assume the pointee has alignment of 4, not 8.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><ul class=""><li style="margin:0px;font-stretch:normal;line-height:normal" class="">Whenever a type has <font face="Menlo" class="">alignas(N)</font>, that alignment will be returned for…both the ABI and the preferred alignments?  It will override both?  Is that right?  I recall it overrides the preferred alignment in Xiangling’s implementation, at least, not sure about the ABI case.</li></ul></div></blockquote><div class="">Yes. Except that alignas can never reduce the alignment below the guaranteed alignment according to the C/C++ language rules, so in effect it can only override preferred alignment. (The nonstandard `__attribute__((aligned))` and  `__attribute__((packed))` can reduce alignment below the default abi alignment, and in that case, you do override both.)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><ul class=""><li style="margin:0px;font-stretch:normal;line-height:normal" class=""><font face="Menlo" class="">alignof(T)</font> / <font face="Menlo" class="">__alignof(T)</font> must return the "ABI" and "preferred" alignments of <font face="Menlo" class="">T</font>, respectively.</li></ul></div></blockquote><div class="">Yep.</div><div class=""> </div><div class="">***: Of course, with the nonstandard packed/aligned attributes, you can create objects which violate these alignment guarantees. If you do so, you must be extremely careful to only access such an object through the appropriately attributed type, and not through a normal unadorned pointer.</div><div class=""><br class=""></div></div></div>
</div></blockquote><br class=""></div><div>Thank you for this great explanation.  I agree that calling the minimum-guaranteed alignment the "ABI" alignment is a big source of confusion.</div><div><br class=""></div><div>It sounds like Xiangling’s most feasible option is to change dynamic memory allocation to build objects using their preferred alignment, but perhaps that may not have any great effect since the minimum alignment used in such cases is already quite high (8 or 16 as you say). </div><div><br class=""></div><div>To the extent their are benefits to <span style="font-style: normal;" class="">accessing</span> a pointee using its "preferred" vs. "ABI" alignment, perhaps Xiangling and the rest of us would benefit from a new attribute which guarantees either that, if a particular type is ever placed within an aggregate, that subobject is aligned according to its preferred alignment (i.e., as if it were not in an aggregate at all).  </div><div><br class=""></div><div>This could either be a class attribute applied to every instance, e.g. </div><div><font face="Menlo" class="">struct __attribute__((preferred_aligned)) Foo {…};</font></div><div><font face="Menlo" class=""><br class=""></font></div><div>Or to support it built in types too it could be enforced as a type qualifier on variables/parameters a la "const", e.g.</div><div>```</div><div><font face="Menlo" class="">void f(</font><span style="font-family: Menlo;" class="">__attribute__((preferred_aligned)) </span><span style="font-family: Menlo;" class="">double *d, </span></div><div><span style="font-family: Menlo;" class="">       __attribute__((preferred_aligned)) Foo *f);</span></div><div>```</div><div><br class=""></div><div>For any type so qualified, we could always use its preferred alignment, as Xiangling wishes.  </div><div><br class=""></div><div>Of course by solving the potential-subobject problem we would then have to confront the interfacing-with-other-compilers problem, but if they were assumed to play along, perhaps there could be significant benefits.</div><div><br class=""></div><div>I’m sure I'm still missing something but in any case I look forward to seeing how this is resolved -- thanks James and good luck Xiangling,</div><div><br class=""></div><div>Dave</div><div><br class=""></div><div><br class=""></div></body></html>