2012-11-17 21:10:52 +00:00
|
|
|
/****************************************************************************
|
|
|
|
**
|
2015-01-28 11:55:39 +00:00
|
|
|
** Copyright (C) 2015 The Qt Company Ltd.
|
|
|
|
** Contact: http://www.qt.io/licensing/
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
2013-06-24 11:50:51 +00:00
|
|
|
** This file is part of the QtQml module of the Qt Toolkit.
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
2014-08-22 06:13:59 +00:00
|
|
|
** $QT_BEGIN_LICENSE:LGPL21$
|
2012-11-17 21:10:52 +00:00
|
|
|
** Commercial License Usage
|
|
|
|
** Licensees holding valid commercial Qt licenses may use this file in
|
|
|
|
** accordance with the commercial license agreement provided with the
|
|
|
|
** Software or, alternatively, in accordance with the terms contained in
|
2015-01-28 11:55:39 +00:00
|
|
|
** a written agreement between you and The Qt Company. For licensing terms
|
|
|
|
** and conditions see http://www.qt.io/terms-conditions. For further
|
|
|
|
** information use the contact form at http://www.qt.io/contact-us.
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
|
|
|
** GNU Lesser General Public License Usage
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU Lesser
|
2014-08-22 06:13:59 +00:00
|
|
|
** General Public License version 2.1 or version 3 as published by the Free
|
|
|
|
** Software Foundation and appearing in the file LICENSE.LGPLv21 and
|
|
|
|
** LICENSE.LGPLv3 included in the packaging of this file. Please review the
|
|
|
|
** following information to ensure the GNU Lesser General Public License
|
|
|
|
** requirements will be met: https://www.gnu.org/licenses/lgpl.html and
|
|
|
|
** http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
2015-01-28 11:55:39 +00:00
|
|
|
** As a special exception, The Qt Company gives you certain additional
|
|
|
|
** rights. These rights are described in The Qt Company LGPL Exception
|
2012-11-17 21:10:52 +00:00
|
|
|
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
|
|
|
|
**
|
|
|
|
** $QT_END_LICENSE$
|
|
|
|
**
|
|
|
|
****************************************************************************/
|
2014-01-24 14:07:34 +00:00
|
|
|
#ifndef QV4VALUE_P_H
|
|
|
|
#define QV4VALUE_P_H
|
2013-04-19 19:24:46 +00:00
|
|
|
|
2015-10-05 08:45:54 +00:00
|
|
|
//
|
|
|
|
// W A R N I N G
|
|
|
|
// -------------
|
|
|
|
//
|
|
|
|
// This file is not part of the Qt API. It exists purely as an
|
|
|
|
// implementation detail. This header file may change from version to
|
|
|
|
// version without notice, or even be removed.
|
|
|
|
//
|
|
|
|
// We mean it.
|
|
|
|
//
|
|
|
|
|
2014-01-25 20:41:31 +00:00
|
|
|
#include <limits.h>
|
|
|
|
|
2012-11-17 21:10:52 +00:00
|
|
|
#include <QtCore/QString>
|
2013-04-15 09:50:16 +00:00
|
|
|
#include "qv4global_p.h"
|
2015-02-13 09:02:28 +00:00
|
|
|
#include <private/qv4heap_p.h>
|
2013-06-25 12:23:35 +00:00
|
|
|
|
2015-07-07 11:13:22 +00:00
|
|
|
/* We cannot rely on QT_POINTER_SIZE to be set correctly on host builds. In qmldevtools the Value objects
|
|
|
|
are only used to store primitives, never object pointers. So we can use the 64-bit encoding. */
|
|
|
|
#ifdef V4_BOOTSTRAP
|
|
|
|
#define QV4_USE_64_BIT_VALUE_ENCODING
|
|
|
|
#elif QT_POINTER_SIZE == 8
|
|
|
|
#define QV4_USE_64_BIT_VALUE_ENCODING
|
|
|
|
#endif
|
|
|
|
|
2013-01-31 09:00:06 +00:00
|
|
|
QT_BEGIN_NAMESPACE
|
|
|
|
|
2013-04-19 11:03:42 +00:00
|
|
|
namespace QV4 {
|
2012-11-17 21:10:52 +00:00
|
|
|
|
2015-02-12 21:17:37 +00:00
|
|
|
namespace Heap {
|
|
|
|
struct Base;
|
|
|
|
}
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
typedef uint Bool;
|
2013-09-15 13:46:36 +00:00
|
|
|
|
2014-03-12 15:55:06 +00:00
|
|
|
struct Q_QML_PRIVATE_EXPORT Value
|
2013-11-02 15:30:26 +00:00
|
|
|
{
|
2014-01-24 14:07:34 +00:00
|
|
|
/*
|
|
|
|
We use two different ways of encoding JS values. One for 32bit and one for 64bit systems.
|
2013-01-28 15:46:09 +00:00
|
|
|
|
2015-03-30 22:21:58 +00:00
|
|
|
In both cases, we use 8 bytes for a value and a different variant of NaN boxing. A Double NaN (actually -qNaN)
|
|
|
|
is indicated by a number that has the top 13 bits set. The other values are usually set to 0 by the
|
2014-01-24 14:07:34 +00:00
|
|
|
processor, and are thus free for us to store other data. We keep pointers in there for managed objects,
|
|
|
|
and encode the other types using the free space given to use by the unused bits for NaN values. This also
|
|
|
|
works for pointers on 64 bit systems, as they all currently only have 48 bits of addressable memory.
|
2012-11-17 21:10:52 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
On 32bit, we store doubles as doubles. All other values, have the high 32bits set to a value that
|
|
|
|
will make the number a NaN. The Masks below are used for encoding the other types.
|
|
|
|
|
2015-03-30 22:21:58 +00:00
|
|
|
On 64 bit, we xor Doubles with (0xffff8000 << 32). That has the effect that no doubles will get encoded
|
2014-01-24 14:07:34 +00:00
|
|
|
with the 13 highest bits all 0. We are now using special values for bits 14-17 to encode our values. These
|
|
|
|
can be used, as the highest valid pointer on a 64 bit system is 2^48-1.
|
|
|
|
|
|
|
|
If they are all 0, we have a pointer to a Managed object. If bit 14 is set we have an integer.
|
|
|
|
This makes testing for pointers and numbers very fast (we have a number if any of the highest 14 bits is set).
|
|
|
|
|
|
|
|
Bit 15-17 is then used to encode other immediates.
|
|
|
|
*/
|
|
|
|
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
quint64 _val;
|
|
|
|
|
|
|
|
Q_ALWAYS_INLINE quint64 val() const { return _val; }
|
|
|
|
Q_ALWAYS_INLINE void setVal(quint64 v) { _val = v; }
|
Fix read of uninitialized value (undefined behavior)
Commit 92836d052efb6d8073136e8507083f93fb60bb80 fixed the type punning
but introduced undefined behavior on 32-bit systems. Detected by GCC 5.2
qv4value_p.h:96:55: error: ‘v.Qti386::QV4::Value::_val’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
qv4scopedvalue_p.h:199:15: note: ‘v.Qti386::QV4::Value::_val’ was declared here
Trace: starting at qv4scopedvalue_p.h:199
Value v;
v = o;
=>
Value &operator=(Heap::Base *o) {
setM(o);
=>
Q_ALWAYS_INLINE void setM(Heap::Base *b) { quint32 v; memcpy(&v, &b,
4); setValue(v); }
=>
Q_ALWAYS_INLINE void setValue(quint32 v) { setTagValue(tag(), v); }
=>
Q_ALWAYS_INLINE quint32 tag() const { return _val >> 32; }
The call to tag() reads from _val before it is initialized. Up until
C++11, uninitialized variables simply had an indeterminate value.
Starting with C++14 (see N3914, resolution of DR1787), reading that
variable not as an unsigned char has undefined behavior. See 8.5
[dcl.init] p12:
... When storage for an object with automatic or dynamic storage
duration is obtained, the object has an indeterminate value, and if no
initialization is performed for the object, that object retains an
indeterminate value until that value is replaced (5.18). [...] If an
indeterminate value is produced by an evaluation, the behavior is
undefined except in the following cases:
[list of cases that use unsigned char]
Change-Id: I42e7ef1a481840699a8dffff1406852f2badabca
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-09-23 05:46:08 +00:00
|
|
|
Q_ALWAYS_INLINE void setValue(quint32 v) { memcpy(&_val, &v, 4); }
|
|
|
|
Q_ALWAYS_INLINE void setTag(quint32 t) { memcpy(4 + (quint8 *)&_val, &t, 4); }
|
2014-01-24 14:07:34 +00:00
|
|
|
|
|
|
|
#if Q_BYTE_ORDER == Q_LITTLE_ENDIAN
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
static inline int valueOffset() { return 0; }
|
|
|
|
static inline int tagOffset() { return 4; }
|
|
|
|
Q_ALWAYS_INLINE void setTagValue(quint32 tag, quint32 value) { _val = quint64(tag) << 32 | value; }
|
|
|
|
Q_ALWAYS_INLINE quint32 value() const { return _val & quint64(~quint32(0)); }
|
|
|
|
Q_ALWAYS_INLINE quint32 tag() const { return _val >> 32; }
|
|
|
|
#else // !Q_LITTLE_ENDIAN
|
|
|
|
static inline int valueOffset() { return 4; }
|
|
|
|
static inline int tagOffset() { return 0; }
|
|
|
|
Q_ALWAYS_INLINE void setTagValue(quint32 tag, quint32 value) { _val = quint64(value) << 32 | tag; }
|
|
|
|
Q_ALWAYS_INLINE quint32 tag() const { return _val & quint64(~quint32(0)); }
|
|
|
|
Q_ALWAYS_INLINE quint32 value() const { return _val >> 32; }
|
|
|
|
#endif
|
|
|
|
|
2016-03-01 14:08:39 +00:00
|
|
|
#if defined(V4_BOOTSTRAP)
|
|
|
|
Q_ALWAYS_INLINE Heap::Base *m() const { Q_UNREACHABLE(); return Q_NULLPTR; }
|
|
|
|
Q_ALWAYS_INLINE void setM(Heap::Base *b) { Q_UNUSED(b); Q_UNREACHABLE(); }
|
|
|
|
#elif defined(QV4_USE_64_BIT_VALUE_ENCODING)
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE Heap::Base *m() const { Heap::Base *b; memcpy(&b, &_val, 8); return b; }
|
|
|
|
Q_ALWAYS_INLINE void setM(Heap::Base *b) { memcpy(&_val, &b, 8); }
|
2015-08-18 08:29:10 +00:00
|
|
|
#else // !QV4_USE_64_BIT_VALUE_ENCODING
|
2016-03-01 14:08:39 +00:00
|
|
|
Q_ALWAYS_INLINE Heap::Base *m() const { Q_STATIC_ASSERT(sizeof(Heap::Base*) == sizeof(quint32)); Heap::Base *b; quint32 v = value(); memcpy(&b, &v, 4); return b; }
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE void setM(Heap::Base *b) { quint32 v; memcpy(&v, &b, 4); setValue(v); }
|
2014-01-24 14:07:34 +00:00
|
|
|
#endif
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
|
|
|
|
Q_ALWAYS_INLINE int int_32() const { int i; quint32 v = value(); memcpy(&i, &v, 4); return i; }
|
|
|
|
Q_ALWAYS_INLINE void setInt_32(int i) { quint32 u; memcpy(&u, &i, 4); setValue(u); }
|
|
|
|
Q_ALWAYS_INLINE uint uint_32() const { return value(); }
|
2014-01-24 14:07:34 +00:00
|
|
|
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifndef QV4_USE_64_BIT_VALUE_ENCODING
|
2014-01-24 14:07:34 +00:00
|
|
|
enum Masks {
|
2014-04-15 22:42:40 +00:00
|
|
|
SilentNaNBit = 0x00040000,
|
|
|
|
NaN_Mask = 0x7ff80000,
|
|
|
|
NotDouble_Mask = 0x7ffa0000,
|
|
|
|
Type_Mask = 0xffffc000,
|
|
|
|
Immediate_Mask = NotDouble_Mask | 0x00004000 | SilentNaNBit,
|
|
|
|
IsNullOrUndefined_Mask = Immediate_Mask | 0x08000,
|
2014-01-24 14:07:34 +00:00
|
|
|
Tag_Shift = 32
|
|
|
|
};
|
|
|
|
enum ValueType {
|
|
|
|
Undefined_Type = Immediate_Mask | 0x00000,
|
2014-04-15 22:42:40 +00:00
|
|
|
Null_Type = Immediate_Mask | 0x10000,
|
|
|
|
Boolean_Type = Immediate_Mask | 0x08000,
|
|
|
|
Integer_Type = Immediate_Mask | 0x18000,
|
|
|
|
Managed_Type = NotDouble_Mask | 0x00000 | SilentNaNBit,
|
|
|
|
Empty_Type = NotDouble_Mask | 0x18000 | SilentNaNBit
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum ImmediateFlags {
|
|
|
|
ConvertibleToInt = Immediate_Mask | 0x1
|
|
|
|
};
|
|
|
|
|
|
|
|
enum ValueTypeInternal {
|
2015-10-22 21:24:35 +00:00
|
|
|
Null_Type_Internal = Null_Type | ConvertibleToInt,
|
|
|
|
Boolean_Type_Internal = Boolean_Type | ConvertibleToInt,
|
|
|
|
Integer_Type_Internal = Integer_Type | ConvertibleToInt,
|
2014-01-24 14:07:34 +00:00
|
|
|
|
|
|
|
};
|
|
|
|
#else
|
|
|
|
static const quint64 NaNEncodeMask = 0xffff800000000000ll;
|
|
|
|
static const quint64 IsInt32Mask = 0x0002000000000000ll;
|
|
|
|
static const quint64 IsDoubleMask = 0xfffc000000000000ll;
|
|
|
|
static const quint64 IsNumberMask = IsInt32Mask|IsDoubleMask;
|
|
|
|
static const quint64 IsNullOrUndefinedMask = 0x0000800000000000ll;
|
|
|
|
static const quint64 IsNullOrBooleanMask = 0x0001000000000000ll;
|
|
|
|
static const quint64 IsConvertibleToIntMask = IsInt32Mask|IsNullOrBooleanMask;
|
|
|
|
|
|
|
|
enum Masks {
|
|
|
|
NaN_Mask = 0x7ff80000,
|
|
|
|
Type_Mask = 0xffff8000,
|
|
|
|
IsDouble_Mask = 0xfffc0000,
|
|
|
|
Immediate_Mask = 0x00018000,
|
|
|
|
IsNullOrUndefined_Mask = 0x00008000,
|
|
|
|
IsNullOrBoolean_Mask = 0x00010000,
|
|
|
|
Tag_Shift = 32
|
|
|
|
};
|
|
|
|
enum ValueType {
|
|
|
|
Undefined_Type = IsNullOrUndefined_Mask,
|
|
|
|
Null_Type = IsNullOrUndefined_Mask|IsNullOrBoolean_Mask,
|
|
|
|
Boolean_Type = IsNullOrBoolean_Mask,
|
|
|
|
Integer_Type = 0x20000|IsNullOrBoolean_Mask,
|
|
|
|
Managed_Type = 0,
|
|
|
|
Empty_Type = Undefined_Type | 0x4000
|
|
|
|
};
|
|
|
|
enum {
|
|
|
|
IsDouble_Shift = 64-14,
|
|
|
|
IsNumber_Shift = 64-15,
|
|
|
|
IsConvertibleToInt_Shift = 64-16,
|
|
|
|
IsManaged_Shift = 64-17
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
enum ValueTypeInternal {
|
2015-10-22 21:24:35 +00:00
|
|
|
Null_Type_Internal = Null_Type,
|
|
|
|
Boolean_Type_Internal = Boolean_Type,
|
|
|
|
Integer_Type_Internal = Integer_Type
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2012-11-17 21:10:52 +00:00
|
|
|
#endif
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
inline unsigned type() const {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return tag() & Type_Mask;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2012-11-17 21:10:52 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
// used internally in property
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isEmpty() const { return tag() == Empty_Type; }
|
2012-11-17 21:10:52 +00:00
|
|
|
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isUndefined() const { return tag() == Undefined_Type; }
|
2015-10-22 21:24:35 +00:00
|
|
|
inline bool isNull() const { return tag() == Null_Type_Internal; }
|
|
|
|
inline bool isBoolean() const { return tag ()== Boolean_Type_Internal; }
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isInteger() const { return (_val >> IsNumber_Shift) == 1; }
|
|
|
|
inline bool isDouble() const { return (_val >> IsDouble_Shift); }
|
|
|
|
inline bool isNumber() const { return (_val >> IsNumber_Shift); }
|
|
|
|
inline bool isManaged() const { return !(_val >> IsManaged_Shift); }
|
|
|
|
inline bool isNullOrUndefined() const { return ((_val >> IsManaged_Shift) & ~2) == 1; }
|
|
|
|
inline bool integerCompatible() const { return ((_val >> IsConvertibleToInt_Shift) & ~2) == 1; }
|
2014-01-24 14:07:34 +00:00
|
|
|
static inline bool integerCompatible(Value a, Value b) {
|
|
|
|
return a.integerCompatible() && b.integerCompatible();
|
2013-01-11 13:33:10 +00:00
|
|
|
}
|
2014-01-24 14:07:34 +00:00
|
|
|
static inline bool bothDouble(Value a, Value b) {
|
|
|
|
return a.isDouble() && b.isDouble();
|
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isNaN() const { return (tag() & 0x7fff8000) == 0x00078000; }
|
2014-01-24 14:07:34 +00:00
|
|
|
#else
|
2015-10-22 21:24:35 +00:00
|
|
|
inline bool isInteger() const { return tag() == Integer_Type_Internal; }
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isDouble() const { return (tag() & NotDouble_Mask) != NotDouble_Mask; }
|
2015-10-22 21:24:35 +00:00
|
|
|
inline bool isNumber() const { return tag() == Integer_Type_Internal || (tag() & NotDouble_Mask) != NotDouble_Mask; }
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
inline bool isManaged() const { return tag() == Managed_Type; }
|
|
|
|
inline bool isNullOrUndefined() const { return (tag() & IsNullOrUndefined_Mask) == Undefined_Type; }
|
|
|
|
inline bool integerCompatible() const { return (tag() & ConvertibleToInt) == ConvertibleToInt; }
|
2014-01-24 14:07:34 +00:00
|
|
|
static inline bool integerCompatible(Value a, Value b) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return ((a.tag() & b.tag()) & ConvertibleToInt) == ConvertibleToInt;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
|
|
|
static inline bool bothDouble(Value a, Value b) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return ((a.tag() | b.tag()) & NotDouble_Mask) != NotDouble_Mask;
|
|
|
|
}
|
|
|
|
inline bool isNaN() const { return (tag() & QV4::Value::NotDouble_Mask) == QV4::Value::NaN_Mask; }
|
|
|
|
#endif
|
|
|
|
Q_ALWAYS_INLINE double doubleValue() const {
|
|
|
|
Q_ASSERT(isDouble());
|
|
|
|
double d;
|
|
|
|
quint64 v = _val;
|
2015-08-18 08:29:10 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v ^= NaNEncodeMask;
|
|
|
|
#endif
|
|
|
|
memcpy(&d, &v, 8);
|
|
|
|
return d;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE void setDouble(double d) {
|
|
|
|
memcpy(&_val, &d, 8);
|
2015-08-18 08:29:10 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
_val ^= NaNEncodeMask;
|
2014-01-24 14:07:34 +00:00
|
|
|
#endif
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ASSERT(isDouble());
|
|
|
|
}
|
2014-01-24 14:07:34 +00:00
|
|
|
inline bool isString() const;
|
|
|
|
inline bool isObject() const;
|
|
|
|
inline bool isInt32() {
|
2015-10-22 21:24:35 +00:00
|
|
|
if (tag() == Integer_Type_Internal)
|
2014-01-24 14:07:34 +00:00
|
|
|
return true;
|
|
|
|
if (isDouble()) {
|
|
|
|
double d = doubleValue();
|
|
|
|
int i = (int)d;
|
|
|
|
if (i == d) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
setInt_32(i);
|
2015-10-22 21:24:35 +00:00
|
|
|
setTag(Integer_Type_Internal);
|
2014-01-24 14:07:34 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
double asDouble() const {
|
2015-10-22 21:24:35 +00:00
|
|
|
if (tag() == Integer_Type_Internal)
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32();
|
2013-09-15 13:46:36 +00:00
|
|
|
return doubleValue();
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2013-09-14 13:08:11 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
bool booleanValue() const {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32();
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
|
|
|
int integerValue() const {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32();
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2013-09-14 13:08:11 +00:00
|
|
|
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE String *stringValue() const {
|
|
|
|
return m() ? reinterpret_cast<String*>(const_cast<Value *>(this)) : 0;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE Object *objectValue() const {
|
|
|
|
return m() ? reinterpret_cast<Object*>(const_cast<Value *>(this)) : 0;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE Managed *managed() const {
|
|
|
|
return m() ? reinterpret_cast<Managed*>(const_cast<Value *>(this)) : 0;
|
2014-07-23 11:56:43 +00:00
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE Heap::Base *heapObject() const {
|
|
|
|
return m();
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2013-09-14 13:08:11 +00:00
|
|
|
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE quint64 &rawValueRef() {
|
|
|
|
return _val;
|
|
|
|
}
|
|
|
|
Q_ALWAYS_INLINE quint64 rawValue() const {
|
|
|
|
return _val;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Q_ALWAYS_INLINE void setRawValue(quint64 raw) { _val = raw; }
|
2013-09-14 13:08:11 +00:00
|
|
|
|
2014-11-01 22:04:20 +00:00
|
|
|
static inline Value fromHeapObject(Heap::Base *m)
|
2014-07-23 11:56:43 +00:00
|
|
|
{
|
|
|
|
Value v;
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setRawValue(0);
|
|
|
|
v.setM(m);
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifndef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setTag(Managed_Type);
|
2014-07-23 11:56:43 +00:00
|
|
|
#endif
|
|
|
|
return v;
|
|
|
|
}
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
int toUInt16() const;
|
|
|
|
inline int toInt32() const;
|
|
|
|
inline unsigned int toUInt32() const;
|
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
bool toBoolean() const;
|
2014-01-24 14:07:34 +00:00
|
|
|
double toInteger() const;
|
|
|
|
inline double toNumber() const;
|
|
|
|
double toNumberImpl() const;
|
|
|
|
QString toQStringNoThrow() const;
|
|
|
|
QString toQString() const;
|
2014-11-11 14:08:30 +00:00
|
|
|
Heap::String *toString(ExecutionEngine *e) const;
|
2014-11-11 12:34:18 +00:00
|
|
|
Heap::Object *toObject(ExecutionEngine *e) const;
|
2014-01-24 14:07:34 +00:00
|
|
|
|
|
|
|
inline bool isPrimitive() const;
|
|
|
|
inline bool tryIntegerConversion() {
|
|
|
|
bool b = integerCompatible();
|
|
|
|
if (b)
|
2015-10-22 21:24:35 +00:00
|
|
|
setTag(Integer_Type_Internal);
|
2014-01-24 14:07:34 +00:00
|
|
|
return b;
|
|
|
|
}
|
2013-09-14 13:08:11 +00:00
|
|
|
|
2015-02-13 09:02:28 +00:00
|
|
|
template <typename T>
|
|
|
|
const T *as() const {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
if (!m() || !isManaged())
|
2015-02-13 09:02:28 +00:00
|
|
|
return 0;
|
|
|
|
|
2015-08-07 11:56:31 +00:00
|
|
|
Q_ASSERT(m()->vtable());
|
2015-02-13 09:02:28 +00:00
|
|
|
#if !defined(QT_NO_QOBJECT_CHECK)
|
|
|
|
static_cast<const T *>(this)->qt_check_for_QMANAGED_macro(static_cast<const T *>(this));
|
|
|
|
#endif
|
2015-08-07 11:56:31 +00:00
|
|
|
const VTable *vt = m()->vtable();
|
2015-02-13 09:02:28 +00:00
|
|
|
while (vt) {
|
|
|
|
if (vt == T::staticVTable())
|
|
|
|
return static_cast<const T *>(this);
|
|
|
|
vt = vt->parent;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
template <typename T>
|
|
|
|
T *as() {
|
|
|
|
return const_cast<T *>(const_cast<const Value *>(this)->as<T>());
|
|
|
|
}
|
|
|
|
|
2014-07-24 09:53:59 +00:00
|
|
|
template<typename T> inline T *cast() {
|
|
|
|
return static_cast<T *>(managed());
|
|
|
|
}
|
|
|
|
template<typename T> inline const T *cast() const {
|
|
|
|
return static_cast<const T *>(managed());
|
|
|
|
}
|
2013-09-14 13:08:11 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
inline uint asArrayIndex() const;
|
2015-02-14 21:46:41 +00:00
|
|
|
#ifndef V4_BOOTSTRAP
|
2015-02-13 14:23:13 +00:00
|
|
|
uint asArrayLength(bool *ok) const;
|
2015-02-14 21:46:41 +00:00
|
|
|
#endif
|
2013-02-14 22:16:50 +00:00
|
|
|
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
ReturnedValue asReturnedValue() const { return _val; }
|
|
|
|
static Value fromReturnedValue(ReturnedValue val) { Value v; v._val = val; return v; }
|
2013-01-11 13:33:10 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
// Section 9.12
|
|
|
|
bool sameValue(Value other) const;
|
2013-01-11 09:13:02 +00:00
|
|
|
|
2015-02-13 11:19:04 +00:00
|
|
|
inline void mark(ExecutionEngine *e);
|
2014-01-24 21:55:39 +00:00
|
|
|
|
|
|
|
Value &operator =(const ScopedValue &v);
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
Value &operator=(ReturnedValue v) { _val = v; return *this; }
|
2014-11-12 15:07:56 +00:00
|
|
|
Value &operator=(Managed *m) {
|
2015-02-13 08:30:11 +00:00
|
|
|
if (!m) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
setTagValue(Undefined_Type, 0);
|
2015-02-13 08:30:11 +00:00
|
|
|
} else {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
_val = reinterpret_cast<Value *>(m)->_val;
|
2015-02-13 08:30:11 +00:00
|
|
|
}
|
2014-01-24 21:55:39 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2014-11-01 22:04:20 +00:00
|
|
|
Value &operator=(Heap::Base *o) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
setM(o);
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifndef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
setTag(Managed_Type);
|
2014-11-12 15:07:56 +00:00
|
|
|
#endif
|
2014-05-09 09:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2014-01-24 21:55:39 +00:00
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
Value &operator=(const Scoped<T> &t);
|
|
|
|
Value &operator=(const Value &v) {
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
_val = v._val;
|
2014-01-24 21:55:39 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2013-01-25 12:23:58 +00:00
|
|
|
|
2015-02-13 13:02:09 +00:00
|
|
|
inline bool Value::isString() const
|
|
|
|
{
|
|
|
|
if (!isManaged())
|
|
|
|
return false;
|
2015-08-07 11:56:31 +00:00
|
|
|
return m() && m()->vtable()->isString;
|
2015-02-13 13:02:09 +00:00
|
|
|
}
|
|
|
|
inline bool Value::isObject() const
|
|
|
|
{
|
|
|
|
if (!isManaged())
|
|
|
|
return false;
|
2015-08-07 11:56:31 +00:00
|
|
|
return m() && m()->vtable()->isObject;
|
2015-02-13 13:02:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline bool Value::isPrimitive() const
|
|
|
|
{
|
|
|
|
return !isObject();
|
|
|
|
}
|
|
|
|
|
2015-02-14 21:46:41 +00:00
|
|
|
inline double Value::toNumber() const
|
|
|
|
{
|
|
|
|
if (isInteger())
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32();
|
2015-02-14 21:46:41 +00:00
|
|
|
if (isDouble())
|
|
|
|
return doubleValue();
|
|
|
|
return toNumberImpl();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef V4_BOOTSTRAP
|
|
|
|
inline uint Value::asArrayIndex() const
|
|
|
|
{
|
2015-08-18 08:29:10 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
2015-02-14 21:46:41 +00:00
|
|
|
if (!isNumber())
|
|
|
|
return UINT_MAX;
|
|
|
|
if (isInteger())
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32() >= 0 ? (uint)int_32() : UINT_MAX;
|
2015-02-14 21:46:41 +00:00
|
|
|
#else
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
if (isInteger() && int_32() >= 0)
|
|
|
|
return (uint)int_32();
|
2015-02-14 21:46:41 +00:00
|
|
|
if (!isDouble())
|
|
|
|
return UINT_MAX;
|
|
|
|
#endif
|
|
|
|
double d = doubleValue();
|
|
|
|
uint idx = (uint)d;
|
|
|
|
if (idx != d)
|
|
|
|
return UINT_MAX;
|
|
|
|
return idx;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
inline
|
|
|
|
ReturnedValue Heap::Base::asReturnedValue() const
|
|
|
|
{
|
|
|
|
return Value::fromHeapObject(const_cast<Heap::Base *>(this)).asReturnedValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-01-25 12:23:58 +00:00
|
|
|
|
2014-03-12 15:55:06 +00:00
|
|
|
struct Q_QML_PRIVATE_EXPORT Primitive : public Value
|
2013-01-25 12:23:58 +00:00
|
|
|
{
|
2014-01-24 14:07:34 +00:00
|
|
|
inline static Primitive emptyValue();
|
|
|
|
static inline Primitive fromBoolean(bool b);
|
|
|
|
static inline Primitive fromInt32(int i);
|
|
|
|
inline static Primitive undefinedValue();
|
|
|
|
static inline Primitive nullValue();
|
|
|
|
static inline Primitive fromDouble(double d);
|
|
|
|
static inline Primitive fromUInt32(uint i);
|
|
|
|
|
2015-03-06 12:48:10 +00:00
|
|
|
using Value::toInt32;
|
|
|
|
using Value::toUInt32;
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
static double toInteger(double fromNumber);
|
|
|
|
static int toInt32(double value);
|
|
|
|
static unsigned int toUInt32(double value);
|
|
|
|
};
|
2013-01-25 12:23:58 +00:00
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
inline Primitive Primitive::undefinedValue()
|
2013-01-25 12:23:58 +00:00
|
|
|
{
|
2014-01-24 14:07:34 +00:00
|
|
|
Primitive v;
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setRawValue(quint64(Undefined_Type) << Tag_Shift);
|
2014-01-24 14:07:34 +00:00
|
|
|
#else
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setRawValue(0);
|
|
|
|
v.setTag(Undefined_Type);
|
|
|
|
v.setValue(0);
|
2014-01-24 14:07:34 +00:00
|
|
|
#endif
|
|
|
|
return v;
|
2013-01-25 12:23:58 +00:00
|
|
|
}
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
inline Primitive Primitive::emptyValue()
|
2013-01-25 12:23:58 +00:00
|
|
|
{
|
2014-01-24 14:07:34 +00:00
|
|
|
Primitive v;
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setTagValue(Value::Empty_Type, 0);
|
2014-01-24 14:07:34 +00:00
|
|
|
return v;
|
2013-01-25 12:23:58 +00:00
|
|
|
}
|
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
inline Primitive Primitive::nullValue()
|
2014-01-24 14:07:34 +00:00
|
|
|
{
|
2015-02-13 14:23:13 +00:00
|
|
|
Primitive v;
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifndef QV4_USE_64_BIT_VALUE_ENCODING
|
2015-10-22 21:24:35 +00:00
|
|
|
v.setRawValue(quint64(Null_Type_Internal) << Tag_Shift);
|
2015-02-13 14:23:13 +00:00
|
|
|
#else
|
2015-10-22 21:24:35 +00:00
|
|
|
v.setTagValue(Null_Type_Internal, 0);
|
2014-06-13 13:11:14 +00:00
|
|
|
#endif
|
2015-02-13 14:23:13 +00:00
|
|
|
return v;
|
|
|
|
}
|
2013-05-06 09:37:53 +00:00
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
inline Primitive Primitive::fromBoolean(bool b)
|
|
|
|
{
|
|
|
|
Primitive v;
|
2015-10-22 21:24:35 +00:00
|
|
|
v.setTagValue(Boolean_Type_Internal, b);
|
2015-02-13 14:23:13 +00:00
|
|
|
return v;
|
|
|
|
}
|
2014-01-24 14:07:34 +00:00
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
inline Primitive Primitive::fromDouble(double d)
|
|
|
|
{
|
|
|
|
Primitive v;
|
|
|
|
v.setDouble(d);
|
|
|
|
return v;
|
|
|
|
}
|
2013-03-06 19:04:43 +00:00
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
inline Primitive Primitive::fromInt32(int i)
|
|
|
|
{
|
|
|
|
Primitive v;
|
2015-10-22 21:24:35 +00:00
|
|
|
v.setTagValue(Integer_Type_Internal, 0); // For mingw482, because it complains, and for VS9, because of internal compiler errors.
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setInt_32(i);
|
2015-02-13 14:23:13 +00:00
|
|
|
return v;
|
|
|
|
}
|
2013-03-06 19:04:43 +00:00
|
|
|
|
2015-02-13 14:23:13 +00:00
|
|
|
inline Primitive Primitive::fromUInt32(uint i)
|
|
|
|
{
|
|
|
|
Primitive v;
|
|
|
|
if (i < INT_MAX) {
|
2015-10-22 21:24:35 +00:00
|
|
|
v.setTagValue(Integer_Type_Internal, 0); // For mingw482, because it complains, and for VS9, because of internal compiler errors.
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
v.setInt_32((int)i);
|
2015-02-13 14:23:13 +00:00
|
|
|
} else {
|
|
|
|
v.setDouble(i);
|
|
|
|
}
|
|
|
|
return v;
|
|
|
|
}
|
2014-01-25 20:41:31 +00:00
|
|
|
|
|
|
|
struct Encode {
|
|
|
|
static ReturnedValue undefined() {
|
|
|
|
return quint64(Value::Undefined_Type) << Value::Tag_Shift;
|
|
|
|
}
|
|
|
|
static ReturnedValue null() {
|
2015-10-22 21:24:35 +00:00
|
|
|
return quint64(Value::Null_Type_Internal) << Value::Tag_Shift;
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Encode(bool b) {
|
2015-10-22 21:24:35 +00:00
|
|
|
val = (quint64(Value::Boolean_Type_Internal) << Value::Tag_Shift) | (uint)b;
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(double d) {
|
|
|
|
Value v;
|
|
|
|
v.setDouble(d);
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
val = v.rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(int i) {
|
2015-10-22 21:24:35 +00:00
|
|
|
val = (quint64(Value::Integer_Type_Internal) << Value::Tag_Shift) | (uint)i;
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(uint i) {
|
|
|
|
if (i <= INT_MAX) {
|
2015-10-22 21:24:35 +00:00
|
|
|
val = (quint64(Value::Integer_Type_Internal) << Value::Tag_Shift) | i;
|
2014-01-25 20:41:31 +00:00
|
|
|
} else {
|
|
|
|
Value v;
|
|
|
|
v.setDouble(i);
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
val = v.rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
Encode(ReturnedValue v) {
|
|
|
|
val = v;
|
|
|
|
}
|
|
|
|
|
2014-11-11 12:34:18 +00:00
|
|
|
Encode(Heap::Base *o) {
|
|
|
|
Q_ASSERT(o);
|
|
|
|
val = Value::fromHeapObject(o).asReturnedValue();
|
|
|
|
}
|
|
|
|
|
2014-01-25 20:41:31 +00:00
|
|
|
operator ReturnedValue() const {
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
quint64 val;
|
|
|
|
private:
|
|
|
|
Encode(void *);
|
|
|
|
};
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
template<typename T>
|
2014-01-25 20:59:15 +00:00
|
|
|
ReturnedValue value_convert(ExecutionEngine *e, const Value &v);
|
2013-05-23 20:13:42 +00:00
|
|
|
|
2015-02-14 21:46:41 +00:00
|
|
|
inline int Value::toInt32() const
|
|
|
|
{
|
|
|
|
if (isInteger())
|
Remove type punning from QV4::Value.
The union in QV4::Value is used to do type punning. In C++, this is
compiler-defined behavior. For example, Clang and GCC will try to detect
it and try to do the proper thing. However, it can play havoc with Alias
Analysis, and it is not guaranteed that some Undefined Behavior (or
Compiler depenedent behavior) might occur.
The really problematic part is the struct inside the union: depending on
the calling convention and the register size, it results in some
exciting code. For example, the AMD64 ABI specifies that a struct of two
values of INTEGER class can be passed in separate registers when doing a
function call. Now, if the AA in the compiler looses track of the fact
that the tag overlaps with the double, you might get:
ecx := someTag
... conditional jumps
double_case:
rdx := xorredDoubleValue
callq someWhere
If the someWhere function checks for the tag first, mayhem ensues: the
double value in rdx does not overwrite the tag that is passed in ecx.
Changing the code to do reinterpret_cast<>s might also give problems
on 32bit architectures, because there is a double, whose size is not the
same as the size of the tag, which could confuse AA.
So, to fix this, the following is changed:
- only have a quint64 field in the QV4::Value, which has the added
benefit that it's very clear for the compiler that it's a POD
- as memcpy is the only approved way to ensure bit-by-bit "conversion"
between types (esp. FP<->non-FP types), change all conversions to use
memcpy. Use bitops (shift/and/or) for anything else.
- only use accessor functions for non-quint64 values
As any modern compiler has memcpy as an intrinsic, the call will be
replaced with one or a few move instructions. The accessor functions
also get inlined, the bitops get optimized, so in all cases the compiler
can generate the most compact code possible.
This patch obsoletes f558bc48585c69de36151248c969a484a969ebb4 (which had
the exact aliassing problem of the double and the tag as described
above).
Change-Id: I60a39d8564be5ce6106403a56a8de90943217006
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
2015-07-08 08:52:59 +00:00
|
|
|
return int_32();
|
2015-02-14 21:46:41 +00:00
|
|
|
double d = isNumber() ? doubleValue() : toNumberImpl();
|
|
|
|
|
|
|
|
const double D32 = 4294967296.0;
|
|
|
|
const double D31 = D32 / 2.0;
|
|
|
|
|
|
|
|
if ((d >= -D31 && d < D31))
|
|
|
|
return static_cast<int>(d);
|
|
|
|
|
|
|
|
return Primitive::toInt32(d);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline unsigned int Value::toUInt32() const
|
|
|
|
{
|
|
|
|
return (unsigned int)toInt32();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2012-11-17 21:10:52 +00:00
|
|
|
|
2013-01-31 09:00:06 +00:00
|
|
|
QT_END_NAMESPACE
|
|
|
|
|
2014-01-24 14:07:34 +00:00
|
|
|
#endif // QV4VALUE_DEF_P_H
|