<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Book Antiqua";
        panose-1:2 4 6 2 5 3 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Book Antiqua",serif;
        font-variant:normal !important;
        color:windowtext;
        text-transform:none;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;
        vertical-align:baseline;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Book Antiqua",serif;
        font-variant:normal !important;
        color:windowtext;
        text-transform:none;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;
        vertical-align:baseline;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-IE link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'>Most likely I misinterpreted your meaning.  I assumed that you were going to make it always illegal to have to any type legalise to more than one register class.  If it is limited to just ‘i1’ I don’t have any concerns.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'>As it happens, we had to do all sorts of tricks to be able to profitably move small SIMD operations between the small and large SIMD registers, and this is not dependent on legalisation anyway.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'>            MartinO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Blank, Guy [mailto:guy.blank@intel.com] <br><b>Sent:</b> 2 February 2017 08:03<br><b>To:</b> Martin J. O'Riordan <martin.oriordan@movidius.com><br><b>Cc:</b> 'LLVM Developers' <llvm-dev@lists.llvm.org><br><b>Subject:</b> RE: [llvm-dev] [X86][AVX512] RFC: make i1 illegal in the Codegen<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>Hi Martin,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span lang=EN-US style='color:#1F497D'>                </span></a><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>Your statement above is true, but making it illegal means that these kinds of SIMD transformations also become illegal.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Not sure I understand what you mean here.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Even with i1 illegal, we would still be able to copy from GPR to K registers when profitable.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Guy<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> Martin J. O'Riordan [<a href="mailto:martin.oriordan@movidius.com">mailto:martin.oriordan@movidius.com</a>] <br><b>Sent:</b> Tuesday, January 24, 2017 15:07<br><b>To:</b> Blank, Guy <<a href="mailto:guy.blank@intel.com">guy.blank@intel.com</a>><br><b>Cc:</b> 'LLVM Developers' <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b> RE: [llvm-dev] [X86][AVX512] RFC: make i1 illegal in the Codegen<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>I can’t comment specifically on the impact on your target and ‘i1’, but there is an issue with LLVM that I do have a concern about.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><span lang=EN-US style='color:black'>Having a type that can be possibly legalized to two different register classes exposes a fundamental limitation of the current instruction selection framework</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>one of the problems I have encountered with LLVM is that I “do” want to be able to legalise and optimise for 2 (or more) register classes for the same type, and LLVM does not really cope with this well.  But it is not ‘i1’ to scalar versus vector that I run into the limitation, but small vectors and large vectors.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>In our architecture, we have two register files that can be used for SIMD operations, one is 32-bits and the other is 128-bits.  But quite often due to register pressure or simply to reduce moving information, I would like to be able to place something like ‘v2i16’ or ‘v4i8’ vectors into either the 32-bit SIMD capable register class or into the low bits of a 128-bit SIMD capable register class.  I expect that other chip architectures have similar capabilities.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>Your statement above is true, but making it illegal means that these kinds of SIMD transformations also become illegal.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>            MartinO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US>From:</span></b><span lang=EN-US> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>] <b>On Behalf Of </b>Blank, Guy via llvm-dev<br><b>Sent:</b> 24 January 2017 11:54<br><b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br><b>Subject:</b> [llvm-dev] [X86][AVX512] RFC: make i1 illegal in the Codegen<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Hi All,<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>AVX-512 introduced the K mask registers and masked operations which make a natural choice for legalizing vectors of i1’s.<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>For example,<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>define <8 x i32> @foo(<8 x i32>%a, <8 x i32*> %p) {<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  %r = call <8 x i32> @llvm.masked.gather.v8i32(<8 x i32*> %p, i32 4, <8 x i1> <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true>, <8 x i32> undef)<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  ret 8 x i32>%r<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>}<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Can be lowered to<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'># BB#0:<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>kxnorw    %k0, %k0, %k1<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>vpgatherqd    (,%zmm1), %ymm0 {%k1}<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>retq<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Legal vectors of i1’s require support for BUILD_VECTOR(i1, i1, .., i1), i1 EXTRACT_VEC_ELEMENT (…) and INSERT_VEC_ELEMENT(i1, …) , so making i1 legal seemed like a sensible decision, and this is the current state in the top of trunk.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>However, making i1 legal affected instruction selection of scalar code as well. Currently, there are cases where operations producing or consuming i1’s are selected (sub-optimally) to instructions that act on K-regs.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US><a href="https://llvm.org/bugs/show_bug.cgi?id=28650"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>PR28650</span></a></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> is an example showing that i1’s live-in or live-out of basic-blocks are being selected to K register classes, even though we don’t want this to happen. This problem does not happen on subtargets without the AVX-512 feature enabled.<br>The following is the AVX-512 code from the bug report:<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'># BB#0:                                 # %entry<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>testb        $1, %dil<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>je        .LBB0_1<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'># BB#2:                                 # %if<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>pushq        %rax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>callq        bar<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>                                        # kill: %AL<def> %AL<kill> %EAX<def><o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>andl        $1, %eax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>kmovw        %eax, %k0<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>addq        $8, %rsp<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>jmp        .LBB0_3<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>.LBB0_1:<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>kxnorw        %k0, %k0, %k0<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>kshiftrw        $15, %k0, %k0<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>.LBB0_3:                                # %else<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>kmovw        %k0, %eax<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>                                        # kill: %AL<def> %AL<kill> %EAX<kill><o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Retq<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>The kmov,kxnor,kshiftr instructions here are the instructions operating on K registers. These are undesirable in the purely scalar input code.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Having a type that can be possibly legalized to two different register classes exposes a fundamental limitation of the current instruction selection framework, and that is we cannot always make the right decision about live-in/live-out i1’s because we cannot see beyond the boundary of the current basic-block we are visiting. As a side-note, with GlobalISel this can be solved, since we see the entire use-def chain at the function level.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Our initial thought was to write a pass that will be run after ISel to correct bad selections. The pass would examine the use-def chains containing values that were selected to K-regsiter classes, and, when profitable, re-assign the values to GPR register classes (and replace the producing/consuming instructions accordingly). But even with this fix-up pass, we would still be losing many ISel pattern-matching rules that will be missed because the instruction set acting on GPR is richer than the instruction set acting on K-regs. For example, a test trying to match the sbb instruction:<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>define i32 @test2(i32 %x, i32 %y, i32 %res) nounwind uwtable readnone ssp {<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>entry:<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  %cmp = icmp ugt i32 %x, %y<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  %dec = sext i1 %cmp to i32<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  %dec.res = add nsw i32 %dec, %res<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>  ret i32 %dec.res<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>}<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Generates the following with AVX2:<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'># BB#0:                                 # %entry<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>cmpl        %edi, %esi<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>sbbl        $0, %edx<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>movl        %edx, %eax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>retq<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>While AVX512 produces:<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'># BB#0:                                 # %entry<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>xorl        %ecx, %ecx<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>cmpl        %esi, %edi<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>movl        $-1, %eax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>cmovbel        %ecx, %eax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>addl        %edx, %eax<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>retq<o:p></o:p></span></p><p style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:27.0pt;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>So we would still end-up with cases where when the AVX-512 feature is enabled, instruction selection for scalar code becomes inferior.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Finally, we suggest to undo the above issues cause by legalizing i1, by making i1 illegal. This would make instruction selection of scalar code identical for both cases when the AVX-512 feature is on and off. As for supporting BUILD_VECTOR, EXTRACT_VEC_ELEMENT and INSERT_VEC_ELEMENT, we believe we can support these operations even when i1 is illegal and the vectors of i1 *<b>are</b>* legal by using the i8 type instead of i1, as it should be implicitly truncated/extended to the element type of the vNi1 vectors. <br>I am now working on a patch that will implement this approach.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> <o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Would appreciate to get feedback and comments.<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Thanks,<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Guy<o:p></o:p></span></p><p style='margin:0cm;margin-bottom:.0001pt'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p><span lang=EN-US>---------------------------------------------------------------------<br>Intel Israel (74) Limited<o:p></o:p></span></p><p><span lang=EN-US>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.<o:p></o:p></span></p><p><span lang=EN-US>---------------------------------------------------------------------<br>Intel Israel (74) Limited<o:p></o:p></span></p><p><span lang=EN-US>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.<o:p></o:p></span></p></div></body></html>