Metadata.cpp:1280:26: warning: zero size arrays are an extension [-Wzero-length-array]
const void *_witnesses[NUM_VALUE_WITNESSES];
^~~~~~~~~~~~~~~~~~~
Metadata.cpp:1366:12: note: in instantiation of member class
'<anonymous>::OpaqueExistentialValueWitnesses<0>::Container' requested here
/*size*/ Container::size(),
^
Metadata.cpp:1448:51: note: in instantiation of static data member '<anonymous
namespace>::OpaqueExistentialValueWitnesses<0>::ValueWitnessTable' requested here
return &OpaqueExistentialValueWitnesses<0>::ValueWitnessTable;
^
1 warning generated.
As an aside, putting a template argument in ALL_CAPS is kinda wierd.
Swift SVN r9787
Instantiate static value witness implementations for the common zero- and one-witness-table cases, which correspond to the "Any" type protocol<> and to single-protocol types. For protocol compositions, instantiate a value witness table that uses the layout information from existential metadata to perform the value witness operations.
Swift SVN r9752
Set up a metadata cache for existential type metadata. Instantiate existential metadata by first sorting the protocol list, so that it is order invariant, precomputing the overall witness table count and class constraint of the composition so it can be cached in the existential metadata.
We still need to implement value witnesses for existential containers in the runtime before this is complete. We can at least test the uniquing and flags computations at this point.
Swift SVN r9727
It'd be nice to eventually report some context information, maybe derived from the location info on the originating 'cond_fail' SIL instruction, but this is a start.
Swift SVN r9589
For consistency with the vague idea that things that are only useful for
compiler developers should go in utils/, not tools/. Unless they need
build system support.
Swift SVN r9433
(This only fails under -DSWIFT_OPTIMIZED=NO; most likely due to an llvm bug.)
We've decided that it's best to specialize each arithmetic builtin that could overflow, instead of calling a separate generic "staticReport" builtin and passing it enough info to produce the message. The main advantage of this approach is that it would be possible for the compiler to customize the message and better link it to the builtin that overflows. For example, the constants that participated in the computation could be printed. In addition, less code will be generated and the compiler could, in the future, automatically emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins. Which are lowered to llvm.op_with_overflow builtins in IRGen after the static diagnostics. If the last argument to the builtins evaluates to true, the overflow is unintentional. CCP uses the builtins to diagnose the overflow detectable at compile time. FixedPoint is changed to rely on these in implementation of primitive arithmetic operations.
Swift SVN r9328
wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
- Added 2 new builtins strunc_with_overflow and utrunc_with_overflow
that perform truncation and produce a compile time error when truncation
overflows.
- Used these builtins instead of trunc to implement "_convertFromBuiltinIntegerLiteral".
- Currently, the builtins are converted to trunc in IRGen, but we should
not be IRGenning code that uses them, since all uses of
"_convertFromBuiltinIntegerLiteral" should be inlined and the arguments
constant folded.
- I had to change a test and the implementation of operator '~' in the standard library
because they assumed that '0xFF' is a valid signed Int8. It is questionable if we should
allow this and if we should treat signed and unsigned integers differently depending on
how they are spelled (decimal or hexadecimal).
* This patch will be further improved (Ex: will start finding overflows on Int64, better
deal with '-128' after the negative integer literal patch is committed.)
Swift SVN r9226
Does what it says on the tin: lays out the fields, storing their offsets into the metadata, and initializes the size, flags, and stride of the value witness table.
Swift SVN r9120
We'll want to use the same logic to lay out generic struct fields at runtime. While we're here, fix a bug where we weren't aligning field offsets prior to storing them in the tuple metadata.
Swift SVN r9117
This was causing massive failures at run-time.
This reverts commit 80081db973ccb7100741fea19ce8e8c116fc410f.
Conflicts:
lib/SILPasses/ConstantPropagation.cpp
test/SILPasses/constant_propagation.swift
test/SILPasses/constant_propagation2.sil
Swift SVN r9050
After talking to John, Joe, and Dave Z, we've decided that it's best to
specialize each arithmetic builtin that could overflow, instead of calling
a separate generic "staticReport" builtin and passing it enough info to
produce the message. The main advantage of this approach is that it
would be possible for the compiler to customize the message and better
link it to the builtin that overflows. For example, the constants that
participated in the computation could be printed. In addition, less code
will be generated and the compiler could, in the future, automatically
emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins.
Which are lowered to llvm.op_with_overflow builtins in IRGen after the
static diagnostics. If the last argument to the builtins evaluates to true,
the overflow is unintentional. CCP uses the builtins to diagnose the overflow
detectable at compile time. FixedPoint is changed to rely on these in
implementation of primitive arithmetic operations.
Swift SVN r9034
- Adds transparent attribute to add/mult/sub on integer types.
- Fix a bug in ConstantPropagation that ensures that the propagation is triggered on StructExtract, when struct is simplified.
- Slightly improve the error message.
Swift SVN r8825
