[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

[James Y Knight via llvm-dev]

>
>
> I understand your goal is to find and fix bugs in software that is
> still under development and CAN be fixed.  I fully endorse that
> goal.  However, that is not the situation that Sony has, and likely
> not what Intel has.  Your proposal will NOT solve our problem.


No, that's not it at all! I'm afraid you've totally misunderstood my
concern.

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 *reliably *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.

As Reid said, -fmax-type-align=N appears to be *almost* that feature,
and something like this little patch (along with documentation update) may
be all that's needed (but this is totally untested).

diff --git clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.cpp
index b23d995683bf..3aef166a690e 100644
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6280,8 +6280,7 @@ CharUnits
CodeGenModule::getNaturalTypeAlignment(QualType T,
   // Cap to the global maximum type alignment unless the alignment
   // was somehow explicit on the type.
   if (unsigned MaxAlign = getLangOpts().MaxTypeAlign) {
-    if (Alignment.getQuantity() > MaxAlign &&
-        !getContext().isAlignmentRequired(T))
+    if (Alignment.getQuantity() > MaxAlign)
       Alignment = CharUnits::fromQuantity(MaxAlign);
   }
   return Alignment;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210419/e8532c19/attachment-0001.html>