<div dir="ltr"><div class="gmail_extra">On Tue, Jan 15, 2013 at 11:45 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank" class="cremed">t.p.northover@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Stephen,<br>
<br>
Chucking in my tuppence,<br>
<div class="im"><br>
> If compiled for ARMv7, the <3 x i64> parameter will become a <3 x i64>*<br>
> indirect parameter.<br>
<br>
</div>This is odd from an AAPCS view. Every other type (except where<br>
required to obey C++ semantics) gets passed directly in ARM. I can't<br>
really see any justification for the pointer and would support<br>
reverting this part.<br>
<div class="im"><br>
> The second major difference that I noticed (also in my sample file) was that<br>
> that we are now losing semantic information about the incoming arguments to<br>
> a function with a vector parameter that requires less than 32 bits of<br>
> storage space (like <2 x i8>, <3 x i8>). In these cases, they are being<br>
> explicitly coerced to a single i32 parameter, which is later used in the<br>
> function body to extract the individual vector components.<br>
<br>
</div>Whether by coincidence or not, I believe i32 is the only justifiable<br>
way to pass that type (unless you decide it gets promoted to an <8 x<br>
i8> and goes in vector registers, which also loses size information).<br>
<br>
In particular, using i16 is incorrect in the big-endian case. For<br>
example, passing the following object in big-endian:<br>
<br>
struct { char c1, c2; } my_obj = {1, 2};<br>
<br>
needs to result in r0 = 0x01020000, which is not a valid i16.<br>
<br></blockquote><div><br></div><div style>I am not actually advocating a switch to i16 here. I actually do suggest keeping the original <2 x i8> so that the type/size is preserved completely. This makes it more consistent with the other vector types and provides greater flexibility for other bitcode consumers. It also keeps the ABI consistent with the previous 3.x releases of LLVM, which is something I thought we were really striving for.</div>
<div style><br></div><div style>Steve</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>