<div dir="ltr"><div>I don't think it's mentioned in Yuanke's mail. dvec.h is a header file that is included with icc that provides C++ wrapper classes around the SSE/AVX vector types that provide operator overloading.</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 19, 2021 at 7:30 PM Luo, Yuanke via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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 lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-3431173859663752789WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-GB">I collected the feedback/requirement from Intel customer as below.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Our software runs in an embedded environment and is processing buffers which are unaligned. Sometimes this misalignment is simply because the buffer allocation is beyond the immediate
 control of our software but  it can also be because we are processing blocks of data which are not multiples of the vector size (e.g., 6, 12 or 24). We can’t just fix our buffers to make them aligned. Our code is complicated and we support multiple instruction
 sets operating using the same algorithms by using templated code. For example:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template<typename DVEC_TYPE><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">void doSomething(DVEC_TYPE* data)<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">{<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  // Trivial example – reality would be something much more substantial, possibly with loops or other function calls.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  *data += 1.0f;<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">}<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Note that we use dvec to help us abstract the ISA, but other similar header-only vector overloading libraries also exist.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">We would then instantiate our function above multiple times for each ISA or data type we care about:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template void doSomething<float>(float* data); // Scalar type useful for debugging algorithm and doing basic testing<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template void doSomething<F32vec8>(F32vec8* data); // Different AVX widths<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template void doSomething<F32vec16>(F32vec16* data);<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template void doSomething<I32vec16>(I32vec16* data); // Different element type<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">The functions are sufficiently large that we don’t want to have to write a different version for each ISA. We know that the incoming data may be mis-aligned and that accessing it directly
 is UB, so we could modify our code to explicitly handle misalignment. Something like:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">template<typename DVEC_TYPE><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">void doSomething(DVEC_TYPE* data)<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">{<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  DVEC_TYPE t;<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  loadu(t, data);<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  t += 1.0f;<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">  storeu(data, t);<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-GB" style="font-family:"Courier New"">}<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">The code has become more verbose, less readable (maintainable, debuggable, etc), and it no longer works with plain scalar types which don’t have loadu/storeu defined unless we start
 defining overloaded helper functions. Also, if `data’ pointed at an array, we’d have to throw some pointer arithmetic into the mix, rather than just using plain `data[IDX]’ syntax. We can certainly write code which could cope with the misalignment explicitly
 but it just ends up becoming messy. Or, we could leverage the hardware to manage this misalignment for us letting the compiler emit the movups instruction, instead of movaps.  <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Until now we have only been using the Intel Compiler, so we have written our code to use ICC’s unaligned operations and hardware support to make our code cleaner. We are looking at porting
 our code to LLVM, but LLVM is making this harder than it needs to be.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
<p class="MsoNormal">Yuanke<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a> <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>>
<br>
<b>Sent:</b> Tuesday, April 20, 2021 4:42 AM<br>
<b>To:</b> <a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a><br>
<b>Cc:</b> Luo, Yuanke <<a href="mailto:yuanke.luo@intel.com" target="_blank">yuanke.luo@intel.com</a>>; <a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>; Liu, Chen3 <<a href="mailto:chen3.liu@intel.com" target="_blank">chen3.liu@intel.com</a>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Maslov, Sergey V <<a href="mailto:sergey.v.maslov@intel.com" target="_blank">sergey.v.maslov@intel.com</a>>; Towner, Daniel <<a href="mailto:daniel.towner@intel.com" target="_blank">daniel.towner@intel.com</a>><br>
<b>Subject:</b> RE: [llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We might still not be fully understanding one another, because this:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">so that you can compile code with under-aligned objects, and have it work as the author expected it to<u></u><u></u></p>
<p class="MsoNormal">sounds like you’re expecting us to recompile the client code that creates the under-aligned objects.  That is literally not possible.  If you do understand that part, great, it’s just not obvious to me from how you’re phrasing things.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I (still) don’t know what Intel is facing.  For Sony’s problem, we would be much more likely to try to do something specific to the APIs that are being abused, rather than something draconian like eliminating alignment requirements for
 everyone.  But of course we have a solution that works for us, so there’s that much more inertia to overcome.<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>>
<br>
<b>Sent:</b> Monday, April 19, 2021 2:30 PM<br>
<b>To:</b> Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
<b>Cc:</b> Luo, Yuanke <<a href="mailto:yuanke.luo@intel.com" target="_blank">yuanke.luo@intel.com</a>>; Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>>; Liu, Chen3 <<a href="mailto:chen3.liu@intel.com" target="_blank">chen3.liu@intel.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>;
 Maslov, Sergey V <<a href="mailto:sergey.v.maslov@intel.com" target="_blank">sergey.v.maslov@intel.com</a>>;
<a href="mailto:daniel.towner@intel.com" target="_blank">daniel.towner@intel.com</a><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal"><br>
I understand your goal is to find and fix bugs in software that is<br>
still under development and CAN be fixed.  I fully endorse that<br>
goal.  However, that is not the situation that Sony has, and likely<br>
not what Intel has.  Your proposal will NOT solve our problem.<u></u><u></u></p>
</blockquote>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">No, that's not it at all! I'm afraid you've totally misunderstood my concern.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My goal is that if we add a compiler feature to address this problem -- so that you can compile code with under-aligned objects, and have it work as the author expected it to --  that the feature <i>reliably </i>addresses the problem, and
 makes such code no longer exhibit Undefined Behavior. The proposed backend change does not accomplish that, but we can implement a feature which will.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As Reid said, -fmax-type-align=N appears to be <i>almost</i> that feature, and something like this little patch (along with documentation update) may be all that's needed (but this is totally untested).<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">diff --git clang/lib/CodeGen/CodeGenModule.cpp clang/lib/CodeGen/CodeGenModule.cpp<br>
index b23d995683bf..3aef166a690e 100644<br>
--- clang/lib/CodeGen/CodeGenModule.cpp<br>
+++ clang/lib/CodeGen/CodeGenModule.cpp<br>
@@ -6280,8 +6280,7 @@ CharUnits CodeGenModule::getNaturalTypeAlignment(QualType T,<br>
   // Cap to the global maximum type alignment unless the alignment<br>
   // was somehow explicit on the type.<br>
   if (unsigned MaxAlign = getLangOpts().MaxTypeAlign) {<br>
-    if (Alignment.getQuantity() > MaxAlign &&<br>
-        !getContext().isAlignmentRequired(T))<br>
+    if (Alignment.getQuantity() > MaxAlign)<br>
       Alignment = CharUnits::fromQuantity(MaxAlign);<br>
   }<br>
   return Alignment;</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>