<div dir="ltr">I'm afraid I'm not yet skilled with LLVL IR, but I think you'd probably want to do something like this:<div><br></div><div><div>#include <stdint.h></div><div><br></div><div>typedef uint32_t elt;</div><div>typedef elt v4 __attribute__ ((vector_size (16)));</div><div><br></div><div>void store(v4 *p, v4 v){</div><div> uintptr_t align = uintptr_t(p) & (sizeof(elt)-1);</div><div> if (align == 0){</div><div> *p = v;</div><div> } else {</div><div> // assert sizeof(elt) == 4</div><div> // assert align == 2</div><div> elt *base = (elt*)(uintptr_t(p) - 2);</div><div> elt lomask = (1<<16)-1;</div><div> elt himask = ~lomask;</div><div> base[0] = (base[0] & lomask) | v[0] << 16;</div><div> base[1] = v[0] >> 16 | v[1] << 16;</div><div> base[2] = v[1] >> 16 | v[2] << 16;</div><div> base[3] = v[2] >> 16 | v[3] << 16;</div><div> base[4] = v[3] >> 16 | (base[4] & himask);</div><div> }</div><div>}</div></div><div><br></div><div>Of course you'll want to convert one LLVM IR to another, not actually insert C code, but you can compile this code and see what IR is produced.</div><div><br></div><div>Interestingly, LLVM manages to optimize this to one elt load, one elt store, and an aligned vector store. Plus some in-registers shuffling, of course.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 5:49 PM, jingu kang <span dir="ltr"><<a href="mailto:jaykang10@gmail.com" target="_blank">jaykang10@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bruce,<br>
<br>
Thanks for response.<br>
<br>
I also think it is not good way. Do you have the other ways to legalize it?<br>
<br>
Thanks,<br>
JinGu Kang<br>
<div class="HOEnZb"><div class="h5"><br>
2016-02-01 13:11 GMT+00:00 Bruce Hoult <<a href="mailto:bruce@hoult.org">bruce@hoult.org</a>>:<br>
> In fact this is a pretty bad legalizing/lowering because you only need to<br>
> load and edit for the first and last values in the vector. The other words<br>
> are completely replaced and don't need to be loaded at all.<br>
><br>
> I think you need to legalize differently when it is not aligned.<br>
><br>
> On Fri, Jan 29, 2016 at 10:07 PM, jingu kang via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi Krzysztof,<br>
>><br>
>> Thanks for response.<br>
>><br>
>> The method is working almost of test cases which use load and store<br>
>> instructions connected with chain. There is other situation. Let's<br>
>> look at a example as follows:<br>
>><br>
>> typedef unsigned short int UV __attribute__((vector_size (8)));<br>
>><br>
>> void test (UV *x, UV *y) {<br>
>> *x = *y / ((UV) { 4, 4, 4, 4 });<br>
>> }<br>
>><br>
>> The target does not support vector type so CodeGen tries to split and<br>
>> scalarize vector to legalize type. While legalizing vector type, the<br>
>> stores of each vector elements nodes are generated from<br>
>> 'DAGTypeLegalizer::SplitVecOp_STORE'. But the stores are not connected<br>
>> with chain. I guess it assumes each vector element's address is<br>
>> different. The each store is lowered to load and store nodes with high<br>
>> and low address but they are not connected with the other store's one.<br>
>> It causes problem. I am not sure how to solve this situation<br>
>> correctly.<br>
>><br>
>> Thanks,<br>
>> JinGu Kang<br>
>><br>
>><br>
>> 2016-01-29 18:11 GMT+00:00 Krzysztof Parzyszek via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br>
>> > On 1/29/2016 10:47 AM, JinGu Kang via llvm-dev wrote:<br>
>> >><br>
>> >><br>
>> >> I am doing it with lowering store as follow:<br>
>> >><br>
>> >> 1. make low and high address with alignment.<br>
>> >> 2. load 2 words from low and high address.<br>
>> >> 3. manipulate them with values to store according to alignment.<br>
>> >> 4. store 2 words modified to low and high address<br>
>> ><br>
>> ><br>
>> > Sounds ok.<br>
>> ><br>
>> ><br>
>> >> In order to keep the order between loads and stores, I have used chain<br>
>> >> and<br>
>> >> glue on the DAG but some passes have mixed it in machine instruction<br>
>> >> level.<br>
>> ><br>
>> ><br>
>> > Glue isn't necessary, chains are sufficient.<br>
>> ><br>
>> > I'm not sure what pass reordered dependent loads and stores, but that<br>
>> > sounds<br>
>> > bad. What matters in cases like this are the MachineMemOperands. If<br>
>> > there<br>
>> > isn't any on a load/store instruction, it should be treated<br>
>> > conservatively<br>
>> > (i.e. alias everything else), if there is one, it'd better be correct.<br>
>> > Wrong MMO could certainly lead to such behavior.<br>
>> ><br>
>> > -Krzysztof<br>
>> ><br>
>> ><br>
>> > --<br>
>> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
>> > hosted by<br>
>> > The Linux Foundation<br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
</font></span></blockquote></div><br></div>