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

via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 19 07:47:52 PDT 2021

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


More information about the llvm-dev mailing list