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

On Mon, Apr 19, 2021 at 5:48 PM via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
>
>                                                                            
|
> > If the proposal here had been: "We should switch X86 from using
> > movaps (alignment-checking) to movups (non-alignment-checking),
> > because movups has a smaller encoding size (or is faster to
> > execute on new microarchitectures, or ...), there'd be no problem.
> >
> > But, that is not what's being proposed here. This proposal is to
> > switch to movups as a workaround for software that has undefined
> > behavior due to misaligned objects. That is misguided, because
> > the proposed change does not fix such code! That the movaps
> > instruction traps in such programs is like a proverbial "canary
> > in a coal mine". It's a result of your program containing
> > alignment-related UB. Removing the canary prevents you from
> > having a dead canary, but it doesn't prevent the mine from
> > exploding.
>
> 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.
> 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.
>
> HTH,
> --paulr
Roman
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> > 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