<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 8, 2014, at 10:20 AM, Robert Khasanov <<a href="mailto:rob.khasanov@gmail.com">rob.khasanov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">You are not right about stores, they have only merge-masking version, not zero-masking.</div></blockquote><div><br></div><div>Great, there is typo in the SDM:</div><div>
                
        
        
                <div class="page" title="Page 527">
                        <div class="section">
                                <div class="layoutArea">
                                        <div class="column"><p><span style="font-size: 9.000000pt; font-family: 'NeoSansIntel'">VMOVDQA32 zmm2/m512 {k1}{z},
zmm1 </span></p>
                                        </div>
                                </div>
                        </div>
                </div></div><div>Could you perhaps let the appropriate people know at Intel?</div><br><blockquote type="cite"><div dir="ltr"><div>As I understand you correctly:</div><div><span style="font-family:arial,sans-serif;font-size:13px">* maskable_custom_mask will have only merge-masking version</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">* maskable_custom_maskz will have only zero-masking version</span><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">* </span><span style="font-size:13px;font-family:arial,sans-serif">maskable_custom derives from </span><span style="font-size:13px;font-family:arial,sans-serif">maskable_custom_mask, and </span><span style="font-size:13px;font-family:arial,sans-serif">maskable_custom_maskz and include also non-masking version.</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">In this plan I will need also add class that will derives from </font><span style="font-family:arial,sans-serif;font-size:13px">maskable_custom_mask and also have non-masking version.. I don't think that it's good hierarchy.. </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Since there is no instructions w/zero-masking, I think deriving maskz from mask is more reasonable (as in my version).</span></div></div></blockquote><div><br></div><div>Yeah given that there does not seem to be an instruction with only zero-masking variant, you’re right.</div><br><blockquote type="cite"><div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Also I want reduce the namings: not repeat mask in multiclass naming: </span><span style="font-family:arial,sans-serif;font-size:13px">maskz_custom instead of </span><span style="font-family:arial,sans-serif;font-size:13px">maskable_custom_maskz, </span><span style="font-size:13px;font-family:arial,sans-serif">mask_custom instead of </span><span style="font-size:13px;font-family:arial,sans-serif">maskable_custom_mask</span></div></div></blockquote><div><br></div><div>It’s confusing not to use something like maskable since this also defines the non-masking version.  That is why I don’t like the current name masking or mask.</div><div><br></div><div>How about:</div><div><br></div><div><font face="Courier New">                 merge_maskable_custom  </font></div><div><font face="Courier New">                        |</font></div><div><font face="Courier New">                        |</font></div><div><div><font face="Courier New"><span class="Apple-tab-span" style="white-space: pre;">        </span>        maskable_custom</font></div><div><font face="Courier New">                    /       \<span class="Apple-tab-span" style="white-space: pre;">       </span>   </font></div><div><font face="Courier New">                   /         \<span class="Apple-tab-span" style="white-space: pre;">                       </span>   </font></div><div><font face="Courier New">          maskable_common   maskable_in_asm</font></div><div><font face="Courier New">            /         \</font></div><div><font face="Courier New">           /            \</font></div><div><font face="Courier New">      maskable        maskable_3src</font></div></div><div>                                                                    </div><div>where merge_maskable_custom only has non-masking and merge-masking and maskable_custom also adds zero-masking?</div><div><br></div><div>Adam</div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">2014-10-08 21:05 GMT+04:00 Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On Oct 8, 2014, at 5:51 AM, Robert Khasanov <<a href="mailto:rob.khasanov@gmail.com" target="_blank">rob.khasanov@gmail.com</a>> wrote:</div><br><blockquote type="cite"><br><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2014-10-08 11:12 GMT+04:00 Adam Nemet<span> </span><span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><div>On Oct 3, 2014, at 11:34 AM, Robert Khasanov <<a href="mailto:rob.khasanov@gmail.com" target="_blank">rob.khasanov@gmail.com</a>> wrote:</div><br><blockquote type="cite"><br><br style="font-family:Helvetica;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2014-10-01 21:38 GMT+04:00 Adam Nemet<span> </span><span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><div>On Oct 1, 2014, at 9:30 AM, Robert Khasanov <<a href="mailto:rob.khasanov@gmail.com" target="_blank">rob.khasanov@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi Adam,<div><br></div><div>About maskings in <span style="font-family:arial,sans-serif;font-size:13px">vextract*x4 instructions. I think we can include VK4 register class and v4i1 type for AVX512F subset as it is needed by instruction semantics. Elena, do you agree? It would be better keep all intrinsics lowering in one place.</span></div></div></blockquote><div><br></div></span><div>Hi Robert,</div><div><br></div><div>I don’t think that a single intrinsic is worth the complication at this point.  I agree that this should be the long term direction but for now it’s probably easier to keep the current simple model in mind that AVX512f only requires v8i1 and above.  So all the strangeness about v4i1 e.g. that it cannot be casted directly from a scalar type, etc. are kept to AVX512vl.</div><div><br></div><div>Once we figure all that out for AVX512vl we will know if it’s worth bringing it into the AVX512f world (for the sake of a single intrinsic or perhaps for some other reason I don’t yet know).</div><div><br></div><div>So my preference would keep the asm-only masking ops for now and experiment with v4i1 in AVX512f context at a later point.   Is that acceptable?</div><span><br></span></div></div></blockquote><div><br></div><div> I think yes. We can do it later.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span><blockquote type="cite"><div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Patches:</span></div><div><br></div><div>0001: LGTM, anyway. It should be committed even though we decided to include VK4 register class for AVX512F subset, because it would be helpful for other instructions (e.g. CMP that will override masking patterns)</div></div></blockquote><div><br></div></span><div>Yeah, I was hoping you’d notice that ;).</div><span><br><blockquote type="cite"><div dir="ltr">0004: I don't understand why you use "AVX512_masking_asm_only" naming. It's not obvious from this name that only non-masking pattern is used.</div></blockquote><div><br></div></span><div>Do you have a better suggestion?  What I was trying to express that for the masking variants we only provide asm support and no code-gen.  Is your problem that the name is too masking focused, i.e. that for the non-masking we do provide code-gen?</div><div><br></div></div></blockquote><div><br></div><div>I was confused that AVX512_masking_asm_only was derived from AVX512_masking_asm multiclass, and it is not obvious what does "only" difference mean.. In implementation I see that you provided only non-masking pattern.</div></div></blockquote><div><br></div></span><div>There should have been a comment as well :(.</div><span><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">May be it would be better to provide AVX512_masking_manual (or another name) derived from AVX512_masking_asm that will have default values (list<dag> Pattern = [], list<dag> MaskingPattern = [], list<dag> ZeroMaskingPattern= []). What do you think?</div></blockquote><div><br></div></span><div>I don’t think that’s a good idea.  The input and output operands should be specified along with the patterns.  So for an instruction with a custom masking and zero-masking pattern (e.g. cmpm), you want to use AVX512_masking_asm (i.e. the class that lets you pass Ins, Outs, Pattern, Masking pattern and Zero-masking pattern.</div><div><br></div><div>So perhaps the naming should be:</div><div><br></div><div>1. masking->maskable  (I think calling this multiclass masking was a mistake since it’s also provides the non-masking variant)</div><div>2. _asm -> _custom</div><div>3. _asm_only -> _in_asm</div><div><br></div><div>So the hierarchy would be like this:</div><div><br></div><div><div><font face="Courier New"><span style="white-space:pre-wrap">     </span><span> </span>       maskable_custom</font></div><div><font face="Courier New">                   <span> </span>/       \<span style="white-space:pre-wrap">      </span><span> </span>  </font></div><div><font face="Courier New">                   /         \<span style="white-space:pre-wrap">                    </span><span> </span>  </font></div><div><font face="Courier New">         <span> </span>maskable_common   maskable_in_asm</font></div><div><font face="Courier New">           <span> </span>/         \</font></div><div><font face="Courier New">           /            \</font></div><div><font face="Courier New">     <span> </span>maskable        maskable_3src</font></div></div><div><br></div><div>Let me know if that sounds more reasonable.</div><span><font color="#888888"><br></font></span></div></div></blockquote><div><br></div><div>The hierarchy looks like reasonable. I suggest to change masking to mask/maskz (similar to intel intrinsics name). So, AVX512_mask_custom includes non-masking and masking versions, and AVX512_maskz_custom is derived from AVX512_mask_custom and includes zero-masking version. Other mask/maskz multiclasses are derived from corresponding mask/maskz parent multiclasses.</div><div>AVX512_mask_custom is useful for instructions with only non-masking and masking versions available (stores, cmp etc.)<br></div></div></blockquote><div><br></div></div></div><div>If I understand you correctly, I rather not create such a bloated hierarchy without existing users.  We can further split the classes if necessary.  For example, I think for cmpm (which I think only has a masking variant — actually implementing zero-masking semantics) we may want to derive from maskable_custom_mask and for stores which only have zero-masking variant we want maskable_custom_maskz.  Then maskable_custom would just derive from both maskable_custom_mask and maskable_custom_maskz.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Adam</div></font></span><div><div class="h5"><div><br></div><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div></div><div>Adam</div></font></span><span><br><blockquote type="cite"><div class="gmail_quote" style="font-family:Helvetica;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Perhaps I should rename these classes to AVX512_maskable or something and call this guy AVX512_maskable_asm_masking?</div><span><font color="#888888"><div><br></div><div>Adam</div></font></span><span><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">2014-10-01 17:47 GMT+04:00 Demikhovsky, Elena<span> </span><span dir="ltr"><<a href="mailto:elena.demikhovsky@intel.com" target="_blank">elena.demikhovsky@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">0003 : LGTM<br><span><br>-  Elena<br><br><br>-----Original Message-----<br>From: Adam Nemet [mailto:<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>]<br>Sent: Wednesday, October 01, 2014 08:57<br>To: Demikhovsky, Elena; Robert Khasanov<br>Cc: LLVM Commits<br>Subject: [AVX512] Add masking variants for vextract*x4<br><br></span><div>Hi Elena and Robert,<br><br>First I tried to implement this with the usual intrinsic lowering but unfortunately because vextract*x4 produces v4* vectors I would have needed VK4 and v4i1 for masking in AVX512f which only come with AVX512vl.  I don't think these intrinsics are worth the hassle making that work so instead I went for asm-only instructions.  Then I have the intrinsics Pat<>s to call the corresponding instruction.<br><br>This approach gave me a chance to incorporate asm-only masking support into the AVX512_masking hierarchy.  See patch 1 and 4.<br><br>Also the masking operand was not supported with the MRMDestReg format, so I've added that too.  See patch 2.<br><br>Please let me know if it looks good to you.<br><br>Thanks,<br>Adam<br><br></div><div>---------------------------------------------------------------------<br>Intel Israel (74) Limited<br><br>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.</div></blockquote></div></div></blockquote></span></div></blockquote></div></blockquote></span></div></blockquote></div></blockquote></div></div></div><br></div></blockquote></div><br></div>
</blockquote></div><br></body></html>