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

[via llvm-dev]

We conditioned it on the PS4 target; no option.  So, PS4 consistently uses unaligned instructions for (temporal) vector load/store.
We get occasional downstream test failures because of this, which we deal with.
--paulr

From: Craig Topper <craig.topper at gmail.com>
Sent: Thursday, April 15, 2021 12:12 PM
To: Robinson, Paul <paul.robinson at sony.com>
Cc: Luo, Yuanke <yuanke.luo at intel.com>; James Y Knight <jyknight at google.com>; Liu, Chen3 <chen3.liu at intel.com>; llvm-dev <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.

Paul, was your patch attached to a command line option, if so what was the default, or did you just always use unaligned instructions?

~Craig


On Thu, Apr 15, 2021 at 8:55 AM via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
I’ve debated whether to chime in, and decided it can’t hurt.

Sony had to do a similar downstream patch for PS4.  Our use-case is pretty constrained, though.  There’s only one toolchain, there’s only one target chip, so we don’t have any portability considerations to think about.  What we do have are games shipping on DVD that can’t be re-released and can’t even necessarily be patched, and a strict backward compatibility requirement.  So, if there’s a game out there that didn’t happen to follow all the alignment requirements, and it worked on console version 1.00, it still has to be working on version 100.00.  (FTR, we’re currently on about 8.00.)

I don’t think we ever seriously considered upstreaming our patch.  The circumstances where it’s really necessary do exist, but are pretty limited.

I don’t think arguments of the form “it’s okay because X Y and Z” are going to be persuasive.  “We have this situation in the following circumstances” might help people understand.
--paulr

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Luo, Yuanke via llvm-dev
Sent: Thursday, April 15, 2021 10:07 AM
To: James Y Knight <jyknight at google.com<mailto:jyknight at google.com>>; Liu, Chen3 <chen3.liu at intel.com<mailto:chen3.liu at intel.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Maslov, Sergey V <sergey.v.maslov at intel.com<mailto:sergey.v.maslov at intel.com>>
Subject: Re: [llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

Yes, replacing aligned move instruction with unaligned move instruction doesn’t solve all the issue that happens in optimization pipeline, but it doesn’t make things worse. One advantage for unaligned move is that it makes the behavior the same no matter the mov instruction is folded or not. Do you think it is worth to support this feature if compiler can help users avoid changing their complex legacy code?

Thanks
Yuanke


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!tXX3whO5BxJF4mKVz5ZthL-dWAyyNJ5QTzg429jWRBk29B5A40HaIujzK8JLzCt8iQ$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210415/7c301b57/attachment.html>