<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 Apr 9, 2014, at 1:28 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">----- Original Message -----<br><blockquote type="cite">From: "Nadav Rotem" <<a href="mailto:nrotem@apple.com">nrotem@apple.com</a>><br>To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>Cc: "Duncan Sands" <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>>, <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>, "Elena Demikhovsky" <<a href="mailto:elena.demikhovsky@intel.com">elena.demikhovsky@intel.com</a>><br>Sent: Wednesday, April 9, 2014 3:20:04 PM<br>Subject: Re: i1 vectors (Re: [PATCH] Fix PR15267)<br><br><br>On Apr 9, 2014, at 1:15 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br><br><blockquote type="cite">----- Original Message -----<br><blockquote type="cite">From: "Duncan Sands" <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>><br>To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>Cc: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>, "Nadav Rotem" <<a href="mailto:nrotem@apple.com">nrotem@apple.com</a>><br>Sent: Wednesday, February 20, 2013 11:38:45 AM<br>Subject: Re: [PATCH] Fix PR15267<br><br>Hi Hal,<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it sounds like you consider <4 x i1> to be bitpacked in<br>memory,<br>like i4.<br>Is that right?<br></blockquote><br>Yes. We need this in order to be consistent with targets that<br>support mask<br>registers.<br></blockquote><br>while it makes sense to me, can you please document this<br>somewhere<br>and ensure<br>that getTypeAllocSize and friends are fixed (should return 1<br>byte!).<br></blockquote><br>Also, we need to make sure that global constants are emitted<br>correctly. Currently, if you make a <N x i1> global constant, it<br>will emit each element into a separate byte.<br></blockquote><br>all kinds of codegen stuff is broken for these types. However<br>even<br>before<br>getting as far as codegen, there are issues at the IR level (type<br>sizes as<br>I mentioned, and also passes that get it wrong for these types).<br>Someone<br>really needs to audit the IR carefully (I would volunteer but I<br>don't<br>think<br>I have time), and then take a careful look at codegen<br>(particularly<br>the type<br>legalization logic; I'm probably the right guy to do that,<br>but...).<br></blockquote><br>To bring this up again, I'm becoming increasingly nervous, seeing<br>all of the i1 vector support, not only in AVX but also in AVX-512,<br>going into the x86 backend while this has not yet been addressed.<br><br>I think that either we should come up with a definitive plan for<br>dealing with this, or we should forbid outright the<br>loading/storing of i1 vectors until we do. The in-register<br>representations of the i1 vectors, as far as I can tell, is fine<br>(so long as the backend provides a self-consistent implementation<br>of build_vector, extract_elemt, etc.). However, providing i1<br>vectors in their current state, as part of the general LLVM IR<br>interface, with an exposed yet inconsistent memory representation,<br>feels like asking for trouble.<br><br></blockquote><br>I think that at this point the representation of i1 vectors is clear.<br>i1s are bit packed in memory. When AVX512 masks are saved to memory<br>they are copied as-is. When an AVX mask are saved to memory they<br>need to be packed. At the moment we have a bug in the code that<br>packs i1s into memory. But this can be fixed. With the exception of<br>the load/store bug everything else already works.<br></blockquote><br>Globals, at least, are still broken:<br><br>$ cat /tmp/g.ll<span class="Apple-converted-space"> </span><br>@Q = global <4 x i1> <i1 0, i1 undef, i1 1, i1 1>, align 16<br><br>$ llc -mtriple=x86_64-pc-linux -mcpu=corei7-avx < /tmp/g.ll<span class="Apple-converted-space"> </span><br><span class="Apple-tab-span" style="white-space: pre;"> </span>.text<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.file<span class="Apple-tab-span" style="white-space: pre;"> </span>"<stdin>"<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.type<span class="Apple-tab-span" style="white-space: pre;"> </span>Q,@object # @Q<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.data<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.globl<span class="Apple-tab-span" style="white-space: pre;"> </span>Q<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.align<span class="Apple-tab-span" style="white-space: pre;"> </span>16<br>Q:<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.byte<span class="Apple-tab-span" style="white-space: pre;"> </span>0 # 0x0<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.zero<span class="Apple-tab-span" style="white-space: pre;"> </span>1<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.byte<span class="Apple-tab-span" style="white-space: pre;"> </span>1 # 0x1<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.byte<span class="Apple-tab-span" style="white-space: pre;"> </span>1 # 0x1<br><span class="Apple-tab-span" style="white-space: pre;"> </span>.size<span class="Apple-tab-span" style="white-space: pre;"> </span>Q, 4<br><br>And so if you try to load from this value then you'll obviously have a problem. Is this what you were talking about, or are you referring to something else?<br></div></blockquote><div><br></div><div>I forgot about globals. Yes, this is also a problem. I meant that SelectionDAGLegalize::LegalizeLoadOps and SelectionDAGLegalize::LegalizeStoreOps don’t know how to pack i1 vectors.</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>-Hal<br><br><blockquote type="cite"><br><br><blockquote type="cite">-Hal<br><br><blockquote type="cite"><br>Ciao, Duncan.<br><br><br></blockquote><br>--<br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<br></blockquote><br><br></blockquote><br>--<span class="Apple-converted-space"> </span><br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory</div></blockquote></div><br></body></html>