<div dir="ltr"><div>The (<span style="color:rgb(85,85,85);letter-spacing:0.2px;white-space:nowrap">i32 extract_vector_elt (v4i16)) doesn't guarantee any particular value in the extra bits of the result. So type legalization may have inserted an AND or SIGN_EXTEND_INREG after the extra node if the original code had zero extended or sign extended the original i16 result. If you target has a well defined behavior for the extra bits that would make an AND or SIGN_EXTEND_INREG reduncant, it might be better to lower this to a target specific opcode and then teach computeKnownBitsForTargetNode or computeNumSignBitsForTarget node the property that your hardware guarantees. This will allow DAG combine to remove extra nodes based on this information.</span></div><div><span style="color:rgb(85,85,85);letter-spacing:0.2px;white-space:nowrap"><br></span></div><div><span style="color:rgb(85,85,85);letter-spacing:0.2px;white-space:nowrap">WebAssembly has explicit patterns for and+vector_extract and sign_extend_inreg+vector_extract to pick specific instructions that have guarantees for the upper bits. But that might not cover all possible cases that a DAG combine with known bits or sign bits information would have been able to do.</span></div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2019 at 6:35 AM Sebastien Le Duc <<a href="mailto:sleduc@kalray.eu">sleduc@kalray.eu</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 class="gmail-m_2596840085627811918WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It works, thanks a lot!<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Vector_extract / vector_insert have a comment that says they are deprecated. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I think this should be updated to say that they can be used when the result’s type is larger than the element type.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Craig Topper [mailto:<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>] <br><b>Sent:</b> Thursday, November 28, 2019 6:42 PM<br><b>To:</b> Sebastien Le Duc<br><b>Cc:</b> llvm-dev<br><b>Subject:</b> Re: [llvm-dev] Question on pattern matching extractelt<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal">I think it’s disallowed by the SDTypeProfile in TargetSelectionDAG.td. You can use vector_extract instead of extractelt which is what some other targets like WebAssembly are doing for this issue. It's type profile is more relaxed on this.<u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Nov 28, 2019 at 8:51 AM Sebastien Le Duc 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><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><div><div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">Hi,<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">I have an issue with pattern matching.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">I have the following SelectionDAG:<u></u><u></u></span></p></div><div><pre style="margin-right:0in;margin-bottom:12pt;margin-left:0in;font-variant-caps:normal;text-decoration-style:initial;text-decoration-color:initial;box-sizing:inherit;word-spacing:0px"><span style="font-family:Consolas;color:black">t13: i32 = extract_vector_elt t2, Constant:i64<1><br><br>That I am trying to match with the following pattern:<u></u><u></u></span></pre></div><pre style="margin-right:0in;margin-bottom:3pt;margin-left:0in;box-sizing:inherit;font-variant-ligatures:none;white-space:pre-wrap;border-radius:4px;font-variant-caps:normal;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px"><span style="font-size:9pt;font-family:Consolas;color:rgb(29,28,29)">def : Pat<(extractelt (v4i16 SingleReg:$v), 1), (SRADd1 SingleReg :$v, (i64 16))>;<u></u><u></u></span></pre></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">But for some reason the pattern does not match.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">It seems to be  due to the fact extract_vector_elt's result type is i32 (because i16 is not a legal type on our processor), but according to the comment in ISDOpcodes.h, it is allowed for EXTRACT_VECTOR_ELT to have a result type larger than the element type of the vector, so I would expect to be able to match such pattern.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">I tried specifying the result type in the pattern:<u></u><u></u></span></p></div><div><pre style="margin-right:0in;margin-bottom:3pt;margin-left:0in;font-variant-caps:normal;text-decoration-style:initial;text-decoration-color:initial;box-sizing:inherit;font-variant-ligatures:none;white-space:pre-wrap;border-radius:4px;word-spacing:0px"><span style="font-size:9pt;font-family:Consolas;color:rgb(29,28,29)">def : Pat<(i32 (extractelt (v4i16 SingleReg:$v), 1)), (SRADd1 SingleReg :$v, (i64 16))>;<u></u><u></u></span></pre><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"> <u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black">But in that case I get a tblgen error:<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif;color:black"><u></u> <u></u></span></p></div><div><div style="margin-left:48pt;margin-right:15pt;box-sizing:inherit;min-width:1px;font-variant-ligatures:common-ligatures;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px"><div><div><div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)">possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records).<br>anonymous_1188: (extractelt:{ *:[] } SingleReg:{ *:[] }:$v, 0:{ *:[i64] })<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)">Is there anyway to match such pattern? <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)">Thanks in advacne!<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)">regards,<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)">Sebastien<u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)"><u></u> <u></u></span></p></div></div></div></div><div><p class="MsoNormal"><span style="font-size:11.5pt;font-family:Arial,sans-serif;color:rgb(29,28,29)"><u></u> <u></u></span></p></div></div></div></div><p class="MsoNormal">_______________________________________________<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" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p></blockquote></div></div></div></div></blockquote></div>