llvm dev - Apr 2021 - [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

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