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

> So the application software is unchangeable, right?
Exactly right.  The application software works fine within itself.

The system software, which we update roughly twice a year, also 
accepted the misaligned data, until Clang was modified to emit the 
aligned (trapping) opcodes.  We had to fix that so the system 
software would continue to allow the (buggy but unchangeable)
application software to continue to work.

Yes, it is indeed the case that we can update the system software 
but not the game software.  I think it would be a distraction to
spell out the scenarios but please accept that it is the case.
--paulr

On 4/19/21 8:20 AM, via llvm-dev wrote:
>> So the application software is unchangeable, right?
> Exactly right.  The application software works fine within itself.
>
> The system software, which we update roughly twice a year, also
> accepted the misaligned data, until Clang was modified to emit the
> aligned (trapping) opcodes.  We had to fix that so the system
> software would continue to allow the (buggy but unchangeable)
> application software to continue to work.
>
> Yes, it is indeed the case that we can update the system software
> but not the game software.  I think it would be a distraction to
> spell out the scenarios but please accept that it is the case.
Out of curiosity, why do you solve this in the backend rather than 
patching your frontend/headers to not specify alignment?  To my 
knowledge (which isn't great in this area), alignment of pointer 
arguments isn't part of the ABI.  Wouldn't tweaking the headers and 
simply recompiling your system libraries get you the same effect?

p.s. The more you explain about your use case, the less motivating I 
find it for upstream.  This sounds like a weird situation you've created 
for yourselves and should bear the cost of maintaining the mitigation 
for.  Just as other downstream distributions do for other issues.  Just 
my 2 cents.
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/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>