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

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

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

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