Hack representation inference to assume current behavior of float32 loads and stores, which include…

Hack representation inference to assume current behavior of float32 loads and stores, which include implicit representation changes.

R=mstarzinger@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=24072

[Michael Starzinger, 2014-09-18 18:38:07]

LGTM.

https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
File test/cctest/compiler/test-run-properties.cc (right):

https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
test/cctest/compiler/test-run-properties.cc:50: volatile U value_a =
static_cast<U>(kValues[i]);
Man, do I love C++ intuitiveness. :)

[Sven Panne, 2014-09-19 06:07:25]

svenpanne@chromium.org changed reviewers:
+ svenpanne@chromium.org

[Sven Panne, 2014-09-19 06:07:26]

https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
File test/cctest/compiler/test-run-properties.cc (right):

https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
test/cctest/compiler/test-run-properties.cc:53: static_cast<double>(value_a) +
static_cast<double>(value_b);
Casting away volatile leads to undefined behavior:

Section 7.1.6.1 The cv-qualifiers
... If an attempt is made to refer to an object defined with a
volatile-qualified type through the use of a glvalue
with a non-volatile-qualified type, the program behavior is undefined.

Why was it introduced here at all? Trying to avoid some compiler optimizations?
If that was the intention, that won't work in general.

[titzer, 2014-09-19 09:28:45]

On 2014/09/19 06:07:26, Sven Panne wrote:
>
https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
> File test/cctest/compiler/test-run-properties.cc (right):
> 
>
https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-ru...
> test/cctest/compiler/test-run-properties.cc:53: static_cast<double>(value_a) +
> static_cast<double>(value_b);
> Casting away volatile leads to undefined behavior:
> 
> Section 7.1.6.1 The cv-qualifiers
> ... If an attempt is made to refer to an object defined with a
> volatile-qualified type through the use of a glvalue
> with a non-volatile-qualified type, the program behavior is undefined.
> 
> Why was it introduced here at all? Trying to avoid some compiler
optimizations?
> If that was the intention, that won't work in general.

Actually the volatile is probably not strictly necessary, but in this case it is
not "casting away" the volatile, it's actually performing an explicit conversion
from uint32_t to U, which mirrors the truncation that is done by the store to
the typed array in the JavaScript code. Unlike static casts from uint32_t to
int8_t and others as previous in this test, C++ doesn't define the precision of
intermediate results, so this change was to force the compiler to convert to
64-bit double and 32-bit float in those respective instantiations of this test
function.

[titzer, 2014-09-19 09:56:24]

Committed patchset #1 manually as 24072 (presubmit successful).