On 2014/03/28 07:57:54, Sven Panne wrote:
NOT LGTM. I think we have to approach the whole problem differently...
How would you like to see this done then? The other approach that I can
see is
to change the functions that pass in a size value so that they don't. This
is
more invasive, but possible.
The underlying problem of having to write different types to some type of
backing store exists. Leaving them as a memcpy is the most portable, but
there
are still compiler issues with trying to optimize it.
Or maybe I'm missing what you think the problem is entirely.
https://codereview.chromium.org/213943002/diff/40001/src/arm64/simulator-arm64.h
File src/arm64/simulator-arm64.h (right):
https://codereview.chromium.org/213943002/diff/40001/src/arm64/simulator-arm64.h#newcode185
src/arm64/simulator-arm64.h:185: value_ = reg.value;
I am slightly worried about using the union trick here: This is undefined
behavior in C++ and we've actually seen compilers (clang IIRC) generating
not
the code one wants here. v8 has the BitCast template for such tricks, but
this
contains a memcpy for just that reason.
https://codereview.chromium.org/213943002/diff/40001/src/arm64/simulator-arm64.h#newcode207
src/arm64/simulator-arm64.h:207: return reg.result;
Same concern here as above: The compiler is free to elide the assignment
of
value_ to reg.value, because according to the rules, reading reg.result
can't
depend on that assignment.
https://codereview.chromium.org/213943002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
