<div dir="ltr">What if we didn't use aligned instructions by default like what PS4 did. And then had a command line option that would "enable alignment exceptions" if someone wants them. Maybe that option should also disable memory folding since memory folding never checks alignment with AVX? Do other targets that have vectors have alignment exceptions like this? We're not obligated to emit code that detects alignment errors. And we already don't if the load gets folded. It seems the problem with the current proposal is that once you have the exception, setting a flag to make it go away is the wrong response.<div><br><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 15, 2021 at 1:10 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Right, I get that this doesn't match what you are doing for PS4, and it doesn't match what Chen3 Liu proposed. To James's point, the -fmax-type-align flag is more principled because it powers down all the other LLVM optimizations that assume aligned pointers have zeros in the low bits.<div><br></div><div>As for how to handle explicit alignment attributes that don't come from type information, maybe we could revisit that behavior, or conditionalize it with a flag. I just mean to say that there is prior art for this direction. We should continue in the direction of a complete solution from the frontend, rather than adding a workaround in the backend.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 15, 2021 at 11:54 AM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">| This sounds like the -fmax-type-align flag:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Well, no, at least not for the PS4 case.  In our case, the type had an alignment attribute but the caller didn’t make sure the allocated memory was aligned properly.  The -fmax-type-align flag explicitly doesn’t do anything in that case,
 if I’m reading it correctly.  (Yes, it’s a bug.  Yes, sanitizers or other testing could have found it.  No, there is no opportunity to do any of the things that would have fixed it correctly.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Really what we did was effectively this:  Pretend X86 doesn’t have a VMOVAPS opcode.  That’s all.  Nothing about memory/operand alignment attributes was modified, IR is unchanged.  Pretend that one machine opcode is missing.  Can’t possibly
 affect anything about IR optimizations, *<b>maybe</b>* something post-ISel would be different but even that is hard to imagine.  (As best I can remember, the only test updates we had to make were to change things like “vmovaps” to “vmov{{u|a}}ps” and done.) 
 It’s like we did <span style="font-family:"Courier New"">s/movaps/movups/g</span> on the assembly output.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I still can’t say I think it should be appropriate to do upstream—no real info yet on Intel’s problem case--but I hope this explains why the bigger hammer (i.e., get Clang involved) doesn’t seem necessary or appropriate.<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Reid Kleckner via llvm-dev<br>
<b>Sent:</b> Thursday, April 15, 2021 12:59 PM<br>
<b>To:</b> James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Liu, Chen3 <<a href="mailto:chen3.liu@intel.com" target="_blank">chen3.liu@intel.com</a>>; Luo, Yuanke <<a href="mailto:yuanke.luo@intel.com" target="_blank">yuanke.luo@intel.com</a>>; Maslov, Sergey V <<a href="mailto:sergey.v.maslov@intel.com" target="_blank">sergey.v.maslov@intel.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Apr 14, 2021 at 11:58 AM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">What I suspect you <i>actually</i> want here is an option to tell Clang not to infer load/store alignments based on object types or alignment attributes -- instead treating everything as being potentially aligned to 1 unless the allocation
 is seen (e.g. global/local variables). Clang would still need to use the usual alignment computation for variable definitions and structure layout, but not memory operations. If clang emits "load ... align 1" instructions in LLVM IR, the right thing would
 then happen in the X86 backend automatically.<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This sounds like the -fmax-type-align flag:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__https:/clang.llvm.org/docs/UsersManual.html*controlling-code-generation__;Iw!!JmoZiZGBv3RvKRSx!uoBVF33nyuM5lbseJ-XKanIeYhdhHW9yOoxyF7zJ56FjUs8jsfdUcuw4AQ96FRBrmA$" target="_blank">https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Explicit alignment attributes are still honored, so some aligned vector instructions may be generated. However, the documentation describes essentially this exact use case.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>