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

[Luo, Yuanke via llvm-dev]

So the application software is unchangeable, right?


-----Original Message-----
From: paul.robinson at sony.com <paul.robinson at sony.com> 
Sent: Monday, April 19, 2021 11:02 PM
To: lebedev.ri at gmail.com
Cc: jyknight at google.com; Liu, Chen3 <chen3.liu at intel.com>; Luo, Yuanke <yuanke.luo at intel.com>; llvm-dev at lists.llvm.org; Maslov, Sergey V <sergey.v.maslov at intel.com>
Subject: RE: [llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

> > Hi James,
> >
> > It's apparent from your reply that you misunderstand one thing:
> > The mine has *already* exploded.
> 
> > I still don't know exactly what Intel is facing, but at Sony we have 
> > games already shipped that CANNOT BE FIXED because they are embedded 
> > in DVD.  It is literally physically impossible to fix the buggy 
> > software, and we have a moral contract with users that their games 
> > will continue to run on all future releases of the console.
> Are they JIT'ed? If not, i'm not really sure how this change to the 
> X86 backend would retroactively "fix" already-compiled code.

No; the actual problem is that buggy game code uses a type that is tagged as 32-byte aligned but allocates data that is 16-byte aligned.
The problem is when the (immutable) game calls (updated) system software that expects 32-byte alignment, and doesn't get it.

The backend change allows our system software not to trap on the misaligned data that the caller gives to it.
--paulr