<div dir="ltr"><div dir="ltr">
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times">Thank you for your explanation. They
are very helpful. I agree that we should only use
"PreferredAlignment" for creating a complete object. I will create a
phabricator patch later based on our discussions here for reviews.<span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times"><span> </span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times">And due to migration reasons, we would
still propose adding an extra flag without default argument instead like the following:<span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times"><span> </span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">/// Set
"NeedsPreferredAlignment" as true only when allocating memory for a
variable on</span><span style="font-family:Times;background:rgb(217,217,217) none repeat scroll 0% 0%"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">/// the stack or
in global/thread local memory. The preferred alignment applies only to a
complete <br></span></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">/// object.</span><span style="font-family:Times;background:rgb(217,217,217) none repeat scroll 0% 0%"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">CharUnits
ASTContext::getTypeAlignInChars(QualType T, <b>bool
NeedsPreferredAlignment</b>) const {<br>
if (<b>NeedsPreferredAlignment</b>)<br>
return
toCharUnitsFromBits(getPreferredTypeAlign(T.getTypePtr())); </span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%"> </span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">
return toCharUnitsFromBits(getTypeAlign(T));<br>
}</span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><br><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%"></span></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif">And in the proposed patch, we will go through "getTypeAlignInChars"
similar functions case-by-case and pass a value to the flag as needed.</p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><br><span style="font-family:Times;color:black;background:rgb(217,217,217) none repeat scroll 0% 0%">
</span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times" lang="EN-US">By doing this, we would expect developers to consciously know and also patch
reviewers consciously agree on which alignment needs to be used.</span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times"><span> </span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times" lang="EN-US"></span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times" lang="EN-US">Later, when we finish the migration process(probably in a few months), we
may remove the flag and replace the "true" flag with invoking
"getPreferredTypeAlign" directly.</span></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><br></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif">Any opinions on this proposal? Please let me know if there are any concerns and suggestions.</p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><br></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif">Thank you,</p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif">Xiangling<br></p><p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times" lang="EN-US"></span><span style="font-family:Times"><span></span></span></p>
<p class="MsoNormal" style="margin:0cm;font-size:12pt;font-family:"Georgia",serif"><span style="font-family:Times"><span> </span></span></p>
<div><span style="font-family:Times" lang="EN-US"><br></span></div><div><span style="font-family:Times" lang="EN-US"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at 12:35 PM David Rector <<a href="mailto:davrecthreads@gmail.com">davrecthreads@gmail.com</a>> wrote:<br></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;"><br><div><br><blockquote type="cite"><div>On Aug 20, 2020, at 9:26 AM, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><br></div><br><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" target="_blank">davrecthreads@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="margin:0px;font-stretch:normal;line-height:normal">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"><br></div><div style="margin:0px;font-stretch:normal;line-height:normal">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>
<li style="margin:0px;font-stretch:normal;line-height:normal"> 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>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><ul>
<li style="margin:0px;font-stretch:normal;line-height:normal">The "preferred" alignment of a type = the actual alignment, at least as large as the ABI alignment, that <i>our</i> compiler will <i>always</i> use in constructing an object of that type.</li></ul></div></blockquote><div>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><ul><li style="margin:0px;font-stretch:normal;line-height:normal">Therefore, whenever we are dealing with an object we know <i>our</i> compiler has constructed, we can use the "preferred" alignment.</li><ul><li style="margin:0px;font-stretch:normal;line-height:normal">And thereby take advantage of target-specific optimizations like AIX.</li></ul>
<li style="margin:0px;font-stretch:normal;line-height:normal">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><li style="margin:0px;font-stretch:normal;line-height:normal">`-And thereby miss out on AIX.</li></ul></ul></div></blockquote><div>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><br></div><div>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> struct Foo { int i; double d; }; </div><div>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><ul><li style="margin:0px;font-stretch:normal;line-height:normal">Whenever a type has <font face="Menlo">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>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><ul><li style="margin:0px;font-stretch:normal;line-height:normal"><font face="Menlo">alignof(T)</font> / <font face="Menlo">__alignof(T)</font> must return the "ABI" and "preferred" alignments of <font face="Menlo">T</font>, respectively.</li></ul></div></blockquote><div>Yep.</div><div> </div><div>***: 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><br></div></div></div>
</div></blockquote><br></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></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></div><div>To the extent their are benefits to <span style="font-style:normal">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></div><div>This could either be a class attribute applied to every instance, e.g. </div><div><font face="Menlo">struct __attribute__((preferred_aligned)) Foo {…};</font></div><div><font face="Menlo"><br></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">void f(</font><span style="font-family:Menlo">__attribute__((preferred_aligned)) </span><span style="font-family:Menlo">double *d, </span></div><div><span style="font-family:Menlo"> __attribute__((preferred_aligned)) Foo *f);</span></div><div>```</div><div><br></div><div>For any type so qualified, we could always use its preferred alignment, as Xiangling wishes. </div><div><br></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></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></div><div>Dave</div><div><br></div><div><br></div></div></blockquote></div></div>