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
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
Make sure that all assigns are lowered by the memory promotion pass, even those
that don't refer to a box. These are always assignments, not initializations.
Swift SVN r7543
to being a semantic assign. The functional difference here is only
for unowned pointers, where now the conversion from strong to unowned
is implicit in the assign.
The logic behind this is that 'assign' is really part of SILGen, that
is only moved later to make it easier to make it be flow sensitive.
Since it is part of SILGen and will be using some of the type lowering
functionality used by SILGen, we should play by its rules.
No functionality change.
Swift SVN r7507
...rather than as a separate step. This avoids duplicating Parse and Sema
work for these. (This is the new and correct version of r7377.)
Also, remove leftover code for building "swift.swift" and friends in lieu
of proper modules. We're not going back to those days. :-)
Swift SVN r7420
This creates a regression in REPL printing for class instances, which now will print the mangled class name of the instance, since Object.className was using the Swift demangler to demangle the type name. REPL printing is getting an overhaul so I think this is OK for now.
Swift SVN r6704
This commit merges EnvironmentVariables and CommandLineArguments into a single
swift.Process global variable. POSIX-dependent parts are available as
extension with "import POSIX".
Original message:
stdlib: split the Process class into a POSIX-dependent (EnvironmentVariables)
and POSIX-independent (CommandLineArguments) parts
Swift SVN r6331
