<div dir="auto">The 256-bit possibly triggers the AVX license on Intel. But it would likely be near other 256-bit instructions anyway.</div><div dir="auto"><br></div><div dir="auto">Does using 128-bit give opportunities for CSE or anything?</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div>On Tue, Jul 25, 2017 at 11:08 AM Elena Demikhovsky via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">delena added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D35839#820377" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35839#820377</a>, @RKSimon wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D35839#820306" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35839#820306</a>, @delena wrote:<br>
><br>
> > We have EVEX to VEX pass to shorten the encoding. But you replaced ymm with xmm. I don't understand why it's better.<br>
><br>
><br>
> This came up on PR32862, which was mainly about AMD 128-bit SIMD ALUs being able to create fewer uops in 256-bit vector code by making use of VEX implicit zeroing of the upper subvectors. Is there any benefit to using xmm on AVX512 hardware or would ymm be better?<br>
<br>
<br>
There is no any diff between xmm and ymm on Intel processors, AFAIK.<br>
I was wrong talking about EVEX2VEX pass, btw. It will do nothing with zmm.<br>
Do AMD processors support AVX-512?<br>
<br>
<br>
<br>
================<br>
Comment at: lib/Target/X86/X86InstrInfo.cpp:7743<br>
   case X86::AVX512_512_SET0:<br>
+  {<br>
+    const TargetRegisterInfo *TRI = &getRegisterInfo();<br>
----------------<br>
Please run clang-format on this code.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D35839" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35839</a><br>
<br>
<br>
<br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature">~Craig</div>