Subzero ARM32: Lower shift and zext, sext, and trunc.

Subzero ARM32: Lower shift and zext, sext, and trunc.

Sext, etc. usually uses shifts (especially for i1 and i64)
so implement shift, then implement those casts.

Implement just enough of bitcast to handle accessing
global addresses (used by some tests). Otherwise,
most other bitcasts are from GPR to FP and FP regs
aren't modeled yet.

Generally following the GCC style for 64-bit shifts.
This takes advantage of the flexible second operand in a "orr",
and takes advantage of the shift-beyond bitwidth saturation.
LLVM is almost the same, but only seems to take advantage
on one side of the 32-bits, not the other side. Should really
get some of the execution tests running to test this behavior!

Fix InstARM32Str::dump(). Str doesn't have a Dest, so use Src.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=4076
R=stichnot@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=66c3d5ecf3b6a6ce3b3a63c85312777ecbacee24

[jvoung (off chromium), 2015-06-04 19:42:05]

jvoung@chromium.org changed reviewers:
+ kschimpf@google.com, mtrofin@chromium.org, stichnot@chromium.org

[Jim Stichnoth, 2015-06-04 22:10:59]

lgtm

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
File src/IceTargetLoweringARM32.cpp (right):

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
src/IceTargetLoweringARM32.cpp:1109: } break;
I've been thinking (in the x86-32 version and also this file) that the lowering
would be tidier and easier to read and reason about if we turn most of the
"break" statements into "return".

Doesn't need to be done in this CL, but I think it would be worthwhile.

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
src/IceTargetLoweringARM32.cpp:1440: Constant *ShiftAmount =
Ctx->getConstantInt32(31);
Maybe use the same variable name for ShiftAmount and Shift above?

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
File tests_lit/llvm2ice_tests/64bit.pnacl.ll (right):

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
tests_lit/llvm2ice_tests/64bit.pnacl.ll:602: define internal i32
@trunc64To32Signed(i64 %padding, i64 %a) {
I'm curious why this padding is needed, here and below.

[jvoung (off chromium), 2015-06-04 23:15:15]

Thanks!

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
File src/IceTargetLoweringARM32.cpp (right):

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
src/IceTargetLoweringARM32.cpp:1109: } break;
On 2015/06/04 22:10:59, stichnot wrote:
> I've been thinking (in the x86-32 version and also this file) that the
lowering
> would be tidier and easier to read and reason about if we turn most of the
> "break" statements into "return".
> 
> Doesn't need to be done in this CL, but I think it would be worthwhile.

That sounds good to me, but will leave for a separate CL.

https://codereview.chromium.org/1143323013/diff/160001/src/IceTargetLoweringA...
src/IceTargetLoweringARM32.cpp:1440: Constant *ShiftAmount =
Ctx->getConstantInt32(31);
On 2015/06/04 22:10:59, stichnot wrote:
> Maybe use the same variable name for ShiftAmount and Shift above?

Done -- picked middle ground of ShiftAmt =)

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
File tests_lit/llvm2ice_tests/64bit.pnacl.ll (right):

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
tests_lit/llvm2ice_tests/64bit.pnacl.ll:602: define internal i32
@trunc64To32Signed(i64 %padding, i64 %a) {
On 2015/06/04 22:10:59, stichnot wrote:
> I'm curious why this padding is needed, here and below.

It's not really necessary, but because on ARM, the first argument is in r0/r1
and the return value is in r0/r1, the redundant copies would be removed in O2
mode, and the function would look empty.

Putting the padding causes this to at least copy out of r2 into r0 so that the
check is more interesting. Otherwise the check would be something like ";
ARM32-NEXT: bx lr"

[Jim Stichnoth, 2015-06-04 23:21:00]

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
File tests_lit/llvm2ice_tests/64bit.pnacl.ll (right):

https://codereview.chromium.org/1143323013/diff/160001/tests_lit/llvm2ice_tes...
tests_lit/llvm2ice_tests/64bit.pnacl.ll:602: define internal i32
@trunc64To32Signed(i64 %padding, i64 %a) {
On 2015/06/04 23:15:15, jvoung wrote:
> On 2015/06/04 22:10:59, stichnot wrote:
> > I'm curious why this padding is needed, here and below.
> 
> It's not really necessary, but because on ARM, the first argument is in r0/r1
> and the return value is in r0/r1, the redundant copies would be removed in O2
> mode, and the function would look empty.
> 
> Putting the padding causes this to at least copy out of r2 into r0 so that the
> check is more interesting. Otherwise the check would be something like ";
> ARM32-NEXT: bx lr"

OK, cool hack. :)

[jvoung (off chromium), 2015-06-05 00:02:37]

Committed patchset #10 (id:180001) manually as
66c3d5ecf3b6a6ce3b3a63c85312777ecbacee24 (tree was closed).