<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><div class="gmail_default">Hi Tim,</div><div class="gmail_default"><br></div><div class="gmail_default">I thought we had agreement at <a href="http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/180464" target="_blank" style="font-family:arial,sans-serif;font-size:13.63636302947998px">http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/180464</a>.</div>
<div><br></div><div>So now I'm confused and don't understand why solution 1 can be an option for big-endian?</div><div><br></div><div>Are you changing your mind and arguing the consistent in-register data layout for big-endian and little-endian? I'm personally happy with that, but it will not work together with GCC, and is violating aapcs64, isn't it?</div>
<div><br></div><div>Thanks,</div><div>-Jiangning</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-12 2:01 GMT+08:00 Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">>     define void @foo( <4 x i64>* %loadaddr, <4 x i32>* %storeaddr ) {<br>
>       %1 = load <4 x i64>* %loadaddr<br>
>       %2 = add <4 x i64> %1, <i64 1, i64 2, i64 3, i64 4><br>
>       %3 = trunc <4 x i64> %2 to <4 x i32><br>
>       store <4 x i32> %3, <4 x i32>* %storeaddr<br>
>       ret void<br>
>     }<br>
><br>
</div><div class="">>   Note that the const value is loaded with ldr q and used by vector instruction, thus swapping of the two upper and the two lower  vector elements.<br>
<br>
</div>I see. I was worried there would be things like this: the remapping<br>
SDNodeXForm I gave takes care of (most) explicit vector indices, but<br>
there are still a whole bunch of implicit ones too. In this case,<br>
concat_vectors, and it has an even simpler problematic example:<br>
<br>
define <4 x i32> @foo(<2 x i32> %l, <2 x i32> %r) {<br>
  %res = shufflevector <2 x i32> %l, <2 x i32> %r, <4 x i32> <i32 0,<br>
i32 1, i32 2, i32 3><br>
  ret <4 x i32> %res<br>
}<br>
<br>
All our patterns assume that the LHS of a concat goes in lanes<br>
[0..N-1] and the RHS goes in [N..2N-1]. This is no longer correct in<br>
the LDR-based big-endian world. We probably have to add to the list:<br>
extract_subvector and scalar_to_vector. I can't *think* of any others,<br>
but that doesn't mean they don't exist. Almost certainly any<br>
instruction ending in a "2" is going to be affected.<br>
<br>
Now, onto solutions...<br>
<br>
1. It's not necessarily too late to switch to canonicalising on<br>
ld1/st1 for the in-register representation. As before, the trade-offs<br>
are: bitcast is odd; function calls & returns are odd; vector indices<br>
are normal though. Probably less efficient code overall. Overall,<br>
implementation is probably quite a lot simpler.<br>
<br>
2. We could obviously split every pattern involving the problematic<br>
nodes into IsLE and IsBE variants. That's the sledge-hammer solution,<br>
and is very ugly.<br>
<br>
3. We could create a new AArch64ISD::CONCAT_LOHI or something during<br>
ISelLowering that reversed it in the BE cases. This probably has nasty<br>
implications for DAGCombiner so it's not really a good idea.<br>
<br>
4. Swapping the arguments to all concat_vectors during ISelLowering is<br>
probably a very bad idea, but I'll mention it for completeness. The<br>
DAGCombiner will not be expecting that switch to have happened and<br>
will almost certainly get it wrong (e.g. by combining<br>
"(extract_element (concat_vectors L, R), 0)" to "(extract_element L,<br>
0)").<br>
<br>
I can't think of any way to make this problem go away with clever<br>
patterns at the moment.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font face="courier new, monospace">Thanks,</font><div><font face="courier new, monospace">-Jiangning</font></div></div>
</div></div>