Lower stacksave and restore intrinsics.

Lower stacksave and restore intrinsics.

Just copies the current stack pointer to/from a variable.

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

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

[Jim Stichnoth, 2014-07-17 16:47:26]

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave.c
File crosstest/test_stacksave.c (right):

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave.c:32: /* NOTE: This has 1 stacksaves, because the vla
is in a loop and should
stacksave :)

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave.c:41: uint32_t vla[size];
It seems to me that a smart compiler could optimize vla[] out entirely.

Also, it seems like the vla[] definition could legitimately be hoisted out of
the loop and you'd be back to the basic vla.

If the vla size were a function of the loop iteration variable, it would be much
harder to hoist.

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave.h
File crosstest/test_stacksave.h (right):

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave.h:1: //===- subzero/crosstest/test_stacksave.h - Test
prototypes ---*- C++ -*-00===//
00?

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
File crosstest/test_stacksave_main.c (right):

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave_main.c:1: //===-
subzero/crosstest/test_stacksave_main.cpp - Driver for tests -----00===//
00?

[jvoung (off chromium), 2014-07-17 20:34:51]

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave.c
File crosstest/test_stacksave.c (right):

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave.c:32: /* NOTE: This has 1 stacksaves, because the vla
is in a loop and should
On 2014/07/17 16:47:25, stichnot wrote:
> stacksave :)

Done.

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave.c:41: uint32_t vla[size];
On 2014/07/17 16:47:25, stichnot wrote:
> It seems to me that a smart compiler could optimize vla[] out entirely.
> 
> Also, it seems like the vla[] definition could legitimately be hoisted out of
> the loop and you'd be back to the basic vla.
> 
> If the vla size were a function of the loop iteration variable, it would be
much
> harder to hoist.

Done.

The compiler did some optimization indeed. It didn't hoist it out, so still had
the stacksave/restore.  However, the compiler noticed the sampling of array
indices and it did optimized out the alloca and computed 3 numbers instead.

Made it touch every entry instead, and made the number sequence a bit more
complicated. I've certainly seen LLVM collapse two nested loops into constant
time operation.

The later function was a bit less optimized, but it also optimized out vla1's
alloca. Adjusted that too.

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
File crosstest/test_stacksave_main.c (right):

https://codereview.chromium.org/396993009/diff/80001/crosstest/test_stacksave...
crosstest/test_stacksave_main.c:1: //===-
subzero/crosstest/test_stacksave_main.cpp - Driver for tests -----00===//
On 2014/07/17 16:47:26, stichnot wrote:
> 00?

Done.

Keys are too close to each other ;-)

[Jim Stichnoth, 2014-07-18 16:55:56]

lgtm

[jvoung (off chromium), 2014-07-18 20:13:04]

Committed patchset #8 manually as r7b34b59 (presubmit successful).