2012-11-17 21:10:52 +00:00
|
|
|
/****************************************************************************
|
|
|
|
**
|
2016-01-19 09:38:36 +00:00
|
|
|
** Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
** Contact: https://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
|
|
|
**
|
2016-01-19 09:38:36 +00:00
|
|
|
** $QT_BEGIN_LICENSE:LGPL$
|
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
|
2016-01-19 09:38:36 +00:00
|
|
|
** and conditions see https://www.qt.io/terms-conditions. For further
|
|
|
|
** information use the contact form at https://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
|
2016-01-19 09:38:36 +00:00
|
|
|
** General Public License version 3 as published by the Free Software
|
|
|
|
** Foundation and appearing in the file LICENSE.LGPL3 included in the
|
|
|
|
** packaging of this file. Please review the following information to
|
|
|
|
** ensure the GNU Lesser General Public License version 3 requirements
|
|
|
|
** will be met: https://www.gnu.org/licenses/lgpl-3.0.html.
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
2016-01-19 09:38:36 +00:00
|
|
|
** GNU General Public License Usage
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU
|
|
|
|
** General Public License version 2.0 or (at your option) the GNU General
|
|
|
|
** Public license version 3 or any later version approved by the KDE Free
|
|
|
|
** Qt Foundation. The licenses are as published by the Free Software
|
|
|
|
** Foundation and appearing in the file LICENSE.GPL2 and LICENSE.GPL3
|
|
|
|
** included in the packaging of this file. Please review the following
|
|
|
|
** information to ensure the GNU General Public License requirements will
|
|
|
|
** be met: https://www.gnu.org/licenses/gpl-2.0.html and
|
|
|
|
** https://www.gnu.org/licenses/gpl-3.0.html.
|
2012-11-17 21:10:52 +00:00
|
|
|
**
|
|
|
|
** $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-10-26 19:56:18 +00:00
|
|
|
#if QT_POINTER_SIZE == 8
|
2015-07-07 11:13:22 +00:00
|
|
|
#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
|
|
|
{
|
2016-06-16 11:39:57 +00:00
|
|
|
private:
|
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
|
|
|
|
2016-09-23 09:34:12 +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, and for a
|
|
|
|
signalling NaN it is the top 14 bits. The other values are usually set to 0 by the
|
|
|
|
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. (Note: we do leave the lower 49 bits available for
|
|
|
|
pointers.)
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
On 64 bit, we xor Doubles with (0xffff8000 << 32). That has the effect that no doubles will
|
|
|
|
get encoded with bits 63-49 all set to 0. We then use bit 48 to distinguish between
|
|
|
|
managed/undefined (0), or Null/Int/Bool/Empty (1). So, storing a 49 bit pointer will leave
|
|
|
|
the top 15 bits 0, which is exactly the 'natural' representation of pointers. If bit 49 is
|
|
|
|
set, bit 48 indicates Empty (0) or integer-convertible (1). Then the 3 bit below that are
|
|
|
|
used to encode Null/Int/Bool.
|
|
|
|
|
|
|
|
On both 32bit and 64bit, Undefined is encoded as a managed pointer with value 0. This is
|
|
|
|
the same as a nullptr.
|
|
|
|
|
|
|
|
Specific bit-sequences:
|
|
|
|
0 = always 0
|
|
|
|
1 = always 1
|
|
|
|
x = stored value
|
|
|
|
a,b,c,d = specific bit values, see notes
|
|
|
|
|
|
|
|
64bit:
|
|
|
|
|
|
|
|
32109876 54321098 76543210 98765432 10987654 32109876 54321098 76543210 |
|
|
|
|
66665555 55555544 44444444 33333333 33222222 22221111 11111100 00000000 | JS Value
|
|
|
|
------------------------------------------------------------------------+--------------
|
|
|
|
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 | Undefined
|
|
|
|
00000000 0000000x xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | Managed (heap pointer)
|
|
|
|
a0000000 0000bc00 00000000 00000000 00000000 00000000 00000000 00000000 | NaN/Inf
|
|
|
|
dddddddd ddddddxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | double
|
|
|
|
00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 | empty (non-sparse array hole)
|
|
|
|
00000000 00000011 10000000 00000000 00000000 00000000 00000000 00000000 | Null
|
|
|
|
00000000 00000011 01000000 00000000 00000000 00000000 00000000 0000000x | Bool
|
|
|
|
00000000 00000011 00100000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | Int
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
- a: xor-ed signbit, always 1 for NaN
|
|
|
|
- bc, xor-ed values: 11 = inf, 10 = sNaN, 01 = qNaN, 00 = boxed value
|
|
|
|
- d: xor-ed bits, where at least one bit is set, so: (val >> (64-14)) > 0
|
|
|
|
- Undefined maps to C++ nullptr, so the "default" initialization is the same for both C++
|
|
|
|
and JS
|
|
|
|
- Managed has the left 15 bits set to 0, so: (val >> (64-15)) == 0
|
|
|
|
- empty, Null, Bool, and Int have the left 14 bits set to 0, and bit 49 set to 1,
|
|
|
|
so: (val >> (64-15)) == 1
|
|
|
|
- Null, Bool, and Int have bit 48 set, indicating integer-convertible
|
|
|
|
- xoring _val with NaNEncodeMask will convert to a double in "natural" representation, where
|
|
|
|
any non double results in a NaN
|
|
|
|
|
|
|
|
32bit:
|
|
|
|
|
|
|
|
32109876 54321098 76543210 98765432 10987654 32109876 54321098 76543210 |
|
|
|
|
66665555 55555544 44444444 33333333 33222222 22221111 11111100 00000000 | JS Value
|
|
|
|
------------------------------------------------------------------------+--------------
|
|
|
|
01111111 11111100 00000000 00000000 00000000 00000000 00000000 00000000 | Undefined
|
|
|
|
01111111 11111100 00000000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | Managed (heap pointer)
|
|
|
|
a1111111 1111bc00 00000000 00000000 00000000 00000000 00000000 00000000 | NaN/Inf
|
|
|
|
xddddddd ddddddxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | double
|
|
|
|
01111111 11111110 00000000 00000000 00000000 00000000 00000000 00000000 | empty (non-sparse array hole)
|
|
|
|
01111111 11111111 10000000 00000000 00000000 00000000 00000000 00000000 | Null
|
|
|
|
01111111 11111111 01000000 00000000 00000000 00000000 00000000 0000000x | Bool
|
|
|
|
01111111 11111111 00100000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx | Int
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
- the upper 32 bits are the tag, the lower 32 bits the value
|
|
|
|
- Undefined has a nullptr in the value, Managed has a non-nullptr stored in the value
|
|
|
|
- a: sign bit, always 0 for NaN
|
|
|
|
- b,c: 00=inf, 01 = sNaN, 10 = qNaN, 11 = boxed value
|
|
|
|
- d: stored double value, as long as not *all* of them are 1, because that's a boxed value
|
|
|
|
(see above)
|
|
|
|
- empty, Null, Bool, and Int have bit 63 set to 0, bits 62-50 set to 1 (same as undefined
|
|
|
|
and managed), and bit 49 set to 1 (where undefined and managed have it set to 0)
|
|
|
|
- Null, Bool, and Int have bit 48 set, indicating integer-convertible
|
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
|
|
|
quint64 _val;
|
|
|
|
|
2016-06-16 11:39:57 +00:00
|
|
|
public:
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE quint64 &rawValueRef() { return _val; }
|
|
|
|
QML_NEARLY_ALWAYS_INLINE quint64 rawValue() const { return _val; }
|
|
|
|
QML_NEARLY_ALWAYS_INLINE void setRawValue(quint64 raw) { _val = raw; }
|
2014-01-24 14:07:34 +00:00
|
|
|
|
2016-09-12 11:15:20 +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; }
|
2016-09-12 11:15:20 +00:00
|
|
|
#else // !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 4; }
|
|
|
|
static inline int tagOffset() { return 0; }
|
|
|
|
#endif
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setTagValue(quint32 tag, quint32 value) { _val = quint64(tag) << 32 | value; }
|
|
|
|
QML_NEARLY_ALWAYS_INLINE quint32 value() const { return _val & quint64(~quint32(0)); }
|
|
|
|
QML_NEARLY_ALWAYS_INLINE quint32 tag() const { return _val >> 32; }
|
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
|
|
|
|
2016-10-21 16:38:50 +00:00
|
|
|
#if defined(QV4_USE_64_BIT_VALUE_ENCODING)
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE Heap::Base *m() const
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
Heap::Base *b;
|
|
|
|
memcpy(&b, &_val, 8);
|
|
|
|
return b;
|
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setM(Heap::Base *b)
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
memcpy(&_val, &b, 8);
|
|
|
|
}
|
2015-08-18 08:29:10 +00:00
|
|
|
#else // !QV4_USE_64_BIT_VALUE_ENCODING
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE Heap::Base *m() const
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
Q_STATIC_ASSERT(sizeof(Heap::Base*) == sizeof(quint32));
|
|
|
|
Heap::Base *b;
|
|
|
|
quint32 v = value();
|
|
|
|
memcpy(&b, &v, 4);
|
|
|
|
return b;
|
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setM(Heap::Base *b)
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
quint32 v;
|
|
|
|
memcpy(&v, &b, 4);
|
2016-09-23 09:34:12 +00:00
|
|
|
setTagValue(Managed_Type_Internal, v);
|
2016-06-16 11:39:57 +00:00
|
|
|
}
|
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
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE int int_32() const
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
return int(value());
|
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setInt_32(int i)
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
|
|
|
setTagValue(Integer_Type_Internal, quint32(i));
|
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE uint uint_32() const { return value(); }
|
2014-01-24 14:07:34 +00:00
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setEmpty()
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
2016-09-23 09:34:12 +00:00
|
|
|
setTagValue(Empty_Type_Internal, value());
|
2016-06-16 11:39:57 +00:00
|
|
|
}
|
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setEmpty(int i)
|
2016-06-16 11:39:57 +00:00
|
|
|
{
|
2016-09-23 09:34:12 +00:00
|
|
|
setTagValue(Empty_Type_Internal, quint32(i));
|
|
|
|
}
|
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setEmpty(quint32 i)
|
2016-10-12 09:15:09 +00:00
|
|
|
{
|
|
|
|
setTagValue(Empty_Type_Internal, i);
|
|
|
|
}
|
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE quint32 emptyValue()
|
2016-10-12 09:15:09 +00:00
|
|
|
{
|
|
|
|
Q_ASSERT(isEmpty());
|
|
|
|
return quint32(value());
|
|
|
|
}
|
|
|
|
|
2016-09-23 09:34:12 +00:00
|
|
|
enum Type {
|
|
|
|
Undefined_Type,
|
|
|
|
Managed_Type,
|
|
|
|
Empty_Type,
|
|
|
|
Integer_Type,
|
|
|
|
Boolean_Type,
|
|
|
|
Null_Type,
|
|
|
|
Double_Type
|
|
|
|
};
|
|
|
|
|
|
|
|
inline Type type() const {
|
|
|
|
if (isUndefined()) return Undefined_Type;
|
|
|
|
if (isManaged()) return Managed_Type;
|
|
|
|
if (isEmpty()) return Empty_Type;
|
|
|
|
if (isInteger()) return Integer_Type;
|
|
|
|
if (isBoolean()) return Boolean_Type;
|
|
|
|
if (isNull()) return Null_Type;
|
|
|
|
Q_ASSERT(isDouble()); return Double_Type;
|
2016-06-16 11:39:57 +00:00
|
|
|
}
|
|
|
|
|
2017-01-25 14:22:25 +00:00
|
|
|
// Shared between 32-bit and 64-bit encoding
|
|
|
|
enum {
|
|
|
|
Tag_Shift = 32
|
|
|
|
};
|
|
|
|
|
|
|
|
// Used only by 64-bit encoding
|
|
|
|
static const quint64 NaNEncodeMask = 0xfffc000000000000ll;
|
|
|
|
enum {
|
|
|
|
IsDouble_Shift = 64-14,
|
|
|
|
IsManagedOrUndefined_Shift = 64-15,
|
|
|
|
IsIntegerConvertible_Shift = 64-16,
|
|
|
|
IsDoubleTag_Shift = IsDouble_Shift - Tag_Shift,
|
|
|
|
Managed_Type_Internal_64 = 0
|
|
|
|
};
|
|
|
|
static const quint64 Immediate_Mask_64 = 0x00020000u; // bit 49
|
|
|
|
|
|
|
|
// Used only by 32-bit encoding
|
2014-01-24 14:07:34 +00:00
|
|
|
enum Masks {
|
2014-04-15 22:42:40 +00:00
|
|
|
SilentNaNBit = 0x00040000,
|
|
|
|
NotDouble_Mask = 0x7ffa0000,
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2017-01-25 14:22:25 +00:00
|
|
|
static const quint64 Immediate_Mask_32 = NotDouble_Mask | 0x00020000u | SilentNaNBit;
|
2014-01-24 14:07:34 +00:00
|
|
|
|
2016-09-23 09:34:12 +00:00
|
|
|
enum {
|
2017-01-25 14:22:25 +00:00
|
|
|
Managed_Type_Internal_32 = NotDouble_Mask
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
|
|
|
|
2017-01-25 14:22:25 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
|
|
|
enum {
|
|
|
|
Managed_Type_Internal = Managed_Type_Internal_64
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2017-01-25 14:22:25 +00:00
|
|
|
static const quint64 Immediate_Mask = Immediate_Mask_64;
|
|
|
|
#else
|
2014-01-24 14:07:34 +00:00
|
|
|
enum {
|
2017-01-25 14:22:25 +00:00
|
|
|
Managed_Type_Internal = Managed_Type_Internal_32
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2017-01-25 14:22:25 +00:00
|
|
|
static const quint64 Immediate_Mask = Immediate_Mask_32;
|
2016-09-23 09:34:12 +00:00
|
|
|
#endif
|
2017-01-25 14:22:25 +00:00
|
|
|
enum {
|
|
|
|
NaN_Mask = 0x7ff80000,
|
|
|
|
};
|
2014-01-24 14:07:34 +00:00
|
|
|
enum ValueTypeInternal {
|
2016-09-23 09:34:12 +00:00
|
|
|
Empty_Type_Internal = Immediate_Mask | 0,
|
|
|
|
ConvertibleToInt = Immediate_Mask | 0x10000u, // bit 48
|
|
|
|
Null_Type_Internal = ConvertibleToInt | 0x08000u,
|
|
|
|
Boolean_Type_Internal = ConvertibleToInt | 0x04000u,
|
|
|
|
Integer_Type_Internal = ConvertibleToInt | 0x02000u
|
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
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isEmpty() const { return tag() == Empty_Type_Internal; }
|
2015-10-22 21:24:35 +00:00
|
|
|
inline bool isNull() const { return tag() == Null_Type_Internal; }
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isBoolean() const { return tag() == Boolean_Type_Internal; }
|
|
|
|
inline bool isInteger() const { return tag() == Integer_Type_Internal; }
|
|
|
|
inline bool isNullOrUndefined() const { return isNull() || isUndefined(); }
|
|
|
|
inline bool isNumber() const { return isDouble() || isInteger(); }
|
|
|
|
|
2015-07-07 11:13:22 +00:00
|
|
|
#ifdef QV4_USE_64_BIT_VALUE_ENCODING
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isUndefined() const { return _val == 0; }
|
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 (_val >> IsDouble_Shift); }
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isManaged() const { return !isUndefined() && ((_val >> IsManagedOrUndefined_Shift) == 0); }
|
2016-12-09 11:31:57 +00:00
|
|
|
inline bool isManagedOrUndefined() const { return ((_val >> IsManagedOrUndefined_Shift) == 0); }
|
2016-09-23 09:34:12 +00:00
|
|
|
|
|
|
|
inline bool integerCompatible() const {
|
|
|
|
return (_val >> IsIntegerConvertible_Shift) == 3;
|
|
|
|
}
|
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();
|
|
|
|
}
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isNaN() const { return (tag() & 0x7ffc0000 ) == 0x00040000; }
|
2014-01-24 14:07:34 +00:00
|
|
|
#else
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isUndefined() const { return tag() == Managed_Type_Internal && value() == 0; }
|
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; }
|
2016-09-23 09:34:12 +00:00
|
|
|
inline bool isManaged() const { return tag() == Managed_Type_Internal && !isUndefined(); }
|
2016-12-09 11:31:57 +00:00
|
|
|
inline bool isManagedOrUndefined() const { return tag() == Managed_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 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
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE double doubleValue() 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
|
|
|
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
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE void setDouble(double 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
|
|
|
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);
|
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
|
|
|
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE String *stringValue() const {
|
2016-05-26 15:46:24 +00:00
|
|
|
if (!isString())
|
|
|
|
return nullptr;
|
2016-11-24 14:39:07 +00:00
|
|
|
return reinterpret_cast<String*>(const_cast<Value *>(this));
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE Object *objectValue() const {
|
2016-05-26 15:46:24 +00:00
|
|
|
if (!isObject())
|
|
|
|
return nullptr;
|
2016-11-24 14:39:07 +00:00
|
|
|
return reinterpret_cast<Object*>(const_cast<Value *>(this));
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE Managed *managed() const {
|
2016-05-26 15:46:24 +00:00
|
|
|
if (!isManaged())
|
|
|
|
return nullptr;
|
2016-11-24 14:39:07 +00:00
|
|
|
return reinterpret_cast<Managed*>(const_cast<Value *>(this));
|
2014-07-23 11:56:43 +00:00
|
|
|
}
|
2016-11-25 10:24:25 +00:00
|
|
|
QML_NEARLY_ALWAYS_INLINE Heap::Base *heapObject() const {
|
2016-12-09 11:31:57 +00:00
|
|
|
return isManagedOrUndefined() ? m() : nullptr;
|
2014-01-24 14:07:34 +00:00
|
|
|
}
|
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.setM(m);
|
2014-07-23 11:56:43 +00:00
|
|
|
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)
|
2016-06-16 11:39:57 +00:00
|
|
|
setTagValue(Integer_Type_Internal, value());
|
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 {
|
2016-11-24 14:39:07 +00:00
|
|
|
if (!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() {
|
2016-05-26 15:46:24 +00:00
|
|
|
if (isManaged())
|
|
|
|
return const_cast<T *>(const_cast<const Value *>(this)->as<T>());
|
|
|
|
else
|
|
|
|
return nullptr;
|
2015-02-13 09:02:28 +00:00
|
|
|
}
|
|
|
|
|
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;
|
2016-12-09 13:46:49 +00:00
|
|
|
inline bool asArrayIndex(uint &idx) 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) {
|
2016-06-16 11:39:57 +00:00
|
|
|
setM(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);
|
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);
|
2014-01-24 14:07:34 +00:00
|
|
|
};
|
2016-09-09 13:37:57 +00:00
|
|
|
V4_ASSERT_IS_TRIVIAL(Value)
|
2013-01-25 12:23:58 +00:00
|
|
|
|
2015-02-13 13:02:09 +00:00
|
|
|
inline bool Value::isString() const
|
|
|
|
{
|
2016-12-09 11:31:57 +00:00
|
|
|
Heap::Base *b = heapObject();
|
|
|
|
return b && b->vtable()->isString;
|
2015-02-13 13:02:09 +00:00
|
|
|
}
|
|
|
|
inline bool Value::isObject() const
|
|
|
|
{
|
2016-12-09 11:31:57 +00:00
|
|
|
Heap::Base *b = heapObject();
|
|
|
|
return b && b->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;
|
|
|
|
}
|
2016-12-09 13:46:49 +00:00
|
|
|
|
|
|
|
inline bool Value::asArrayIndex(uint &idx) const
|
|
|
|
{
|
|
|
|
if (!isDouble()) {
|
|
|
|
if (isInteger() && int_32() >= 0) {
|
|
|
|
idx = (uint)int_32();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
double d = doubleValue();
|
|
|
|
idx = (uint)d;
|
2017-01-25 11:33:51 +00:00
|
|
|
return (idx == d && idx != UINT_MAX);
|
2016-12-09 13:46:49 +00:00
|
|
|
}
|
2015-02-14 21:46:41 +00:00
|
|
|
#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();
|
2016-10-12 09:15:09 +00:00
|
|
|
inline static Primitive emptyValue(uint v);
|
2014-01-24 14:07:34 +00:00
|
|
|
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;
|
2016-09-23 09:34:12 +00:00
|
|
|
v.setM(Q_NULLPTR);
|
2014-01-24 14:07:34 +00:00
|
|
|
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;
|
2016-09-23 09:34:12 +00:00
|
|
|
v.setEmpty(0);
|
2014-01-24 14:07:34 +00:00
|
|
|
return v;
|
2013-01-25 12:23:58 +00:00
|
|
|
}
|
|
|
|
|
2016-10-12 09:15:09 +00:00
|
|
|
inline Primitive Primitive::emptyValue(uint e)
|
|
|
|
{
|
|
|
|
Primitive v;
|
|
|
|
v.setEmpty(e);
|
|
|
|
return v;
|
|
|
|
}
|
|
|
|
|
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-10-22 21:24:35 +00:00
|
|
|
v.setTagValue(Null_Type_Internal, 0);
|
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;
|
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) {
|
2016-06-16 11:39:57 +00:00
|
|
|
v.setTagValue(Integer_Type_Internal, 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() {
|
2016-09-23 09:34:12 +00:00
|
|
|
return Primitive::undefinedValue().rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
static ReturnedValue null() {
|
2016-09-23 09:34:12 +00:00
|
|
|
return Primitive::nullValue().rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Encode(bool b) {
|
2016-09-23 09:34:12 +00:00
|
|
|
val = Primitive::fromBoolean(b).rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(double d) {
|
2016-09-23 09:34:12 +00:00
|
|
|
val = Primitive::fromDouble(d).rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(int i) {
|
2016-09-23 09:34:12 +00:00
|
|
|
val = Primitive::fromInt32(i).rawValue();
|
2014-01-25 20:41:31 +00:00
|
|
|
}
|
|
|
|
Encode(uint i) {
|
2016-09-23 09:34:12 +00:00
|
|
|
val = Primitive::fromUInt32(i).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();
|
|
|
|
}
|
|
|
|
|
2017-01-27 08:57:00 +00:00
|
|
|
struct ValueArray {
|
|
|
|
uint size;
|
|
|
|
uint alloc;
|
|
|
|
Value v[1];
|
|
|
|
|
|
|
|
inline Value &operator[] (uint index) {
|
|
|
|
Q_ASSERT(index < alloc);
|
|
|
|
return v[index];
|
|
|
|
}
|
|
|
|
inline const Value &operator[] (uint index) const {
|
|
|
|
Q_ASSERT(index < alloc);
|
|
|
|
return v[index];
|
|
|
|
}
|
|
|
|
};
|
2015-02-14 21:46:41 +00:00
|
|
|
|
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
|