<div dir="ltr">OK, I'm clear on scalars. Data races are thankfully OK in this context.<div><br></div><div>Densely packing vectors sounds efficient and is clear in the case where lanes * width is a multiple of 8 bits. I don't think I understand how it works in other cases.</div><div><br></div><div>If we could take store <4 x i8> truncating to <4 x i7> as an example. This can be converted into four scalar i8 -> i7 stores with corresponding increments to the address, in which case the final layout in memory is 0b01111111011111110111111101111111. Or it can be written as a packed vector which I think would resemble 0b00001111111111111111111111111111.</div><div><br></div><div>This would mean the memory layout changes depending on how/whether the legaliser breaks large vectors down into smaller types. Is this the case? For example, <4xi32> => <4 x i31> converts to two <2 x i32> => <2 x i31> stores on a target with <2 x i32> legal but would not be split if <4 x i32> were declared legal.</div><div><br><div class="gmail_extra">Thanks</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jon</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 7:41 PM, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<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"><span class="gmail-">On 9/15/2017 11:30 AM, Jon Chesterfield wrote:<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">
Interesting, thank you. I expected both answers to be "unchanged" so was surprised by the zero extend in the legaliser.<br>
<br>
The motivation here is that it's faster for us to load N bytes, apply whatever masks are necessary to reproduce the truncating store then store all N bytes. This is only a good plan if there's no change to the semantics :)<br>
</blockquote>
<br></span>
See <a href="http://llvm.org/docs/LangRef.html#store-instruction" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.h<wbr>tml#store-instruction</a> .  In general, you have to be careful to avoid data races, but that might not apply to your target.<span class="gmail-"><br>
<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">
Are scalar integer types zero extended to the next multiple of 8 or to the next power of 2 greater than 7? For example, i17 => i24 or i17 => i32?<br>
</blockquote>
<br></span>
Multiple of 8.<span class="gmail-"><br>
<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">
I think this means truncating stores of vector types will introduce zero bits at the end of each element instead grouping all the zeros at the end. For example, <i6 63, i6 63> writes to sixteen bits as 0b0011111100111111, not as 0b0000111111111111?<br>
</blockquote>
<br></span>
Vector types are tightly packed, so <8 x i1> is 1 byte, not 8 bytes.<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
-Eli<br>
<br>
-- <br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
</div></div></blockquote></div><br></div></div></div>