We now produce:
t.swift:1:15: error: negative integer '-9223372036854775808' overflows when stored into unsigned type 'UInt'
var x: UInt = -0x8000_0000_0000_0000
^
Swift SVN r27797
On that testcase, we now generate:
t.swift:8:22: error: integer literal '123456' overflows when stored into 'UInt8'
case tooFarByFar = 123456
^
t.swift:7:8: error: integer literal '256' overflows when stored into 'UInt8'
case twoHundredFiftySix
^
instead of spitting out some warnings with no source loc (which Xcode eats).
This patch:
- Propagates source locations for literals when synthesizing code in various places,
so we get the right diagnostic at the right spot.
- Improves the constant folding SIL Pass to print the value overflowing, which is
necessary for cases with an implicit value (like 256 above), and is general goodness
for the QoI of the diagnostic anyway.
Swift SVN r27756
Fix a few places in diagnose unreachable, which were emitting false diagnostics after enabling this optimization.
This commit does not disable and remove the special-casing for bridging conversions in the CSApply yet. Let's wait a bit and see that everything works properly after my recent cast optimizations changes. If everything is OK, we can remove the code from CSApply.
This time it does not break the Alamofire external project (rdar://20579035).
rdar://20467603
Swift SVN r27513
Fix a few places in diagnose unreachable, which were emitting false diagnostics after enabling this optimization.
This commit does not disable and remove the special-casing for bridging conversions in the CSApply yet. Let's wait a bit and see that everything works properly after my recent cast optimizations changes. If everything is OK, we can remove the code from CSApply.
Swift SVN r27379
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
In every instance, we were just creating the StringConcatenationOptimizer and
then invoking optimize on it. This is a cleaner solution since the details of
how we perform the string concatenation are hidden in Local.cpp instead of being
in a header.
NFC.
Swift SVN r25341
Note that it done in both constant-propagation and in sil-combine. SILCombine catches cases that are exposed by inlining and other simplifications (which wouldn’t be guaranteed), but the constant prop case handles the guaranteed ones.
rdar://19125926
Swift SVN r23656
It returns the argument and specifies that the value is not negative.
It has only an effect if the argument is a load or call.
The effect of this builtin is that for the load/call argument a positive range metadata is created in llvm ir.
I also added a public function _assumeNonNegative(x: Int) -> Int in the stdlib.
To be on the save side, I prefixed it with an underscore. But maybe it makes sense to make it available for all users.
Swift SVN r23582
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
overflow and diagnosed with an error, e.g.:
ov.swift:2:19: error: arithmetic operation '126 + 2' (on type 'Int8') results in an overflow
let v = Int8(126) + (1+1)
~~~~~~~~~ ^ ~~~~~
Swift SVN r22905
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This builtin only becomes unreachable when assert_configuration calls have been folded, allowing library-level checks to become unreachable based on the assert level.
Swift SVN r17322
This patch adds support for a builtin function assert_configuration that is
replaced by constant progpagation by an appropriate value dependent on a compile
time setting. This replacement can also be disabled when serializing sil for a
library.
Using this mechanism we implement assertions that can be disabled (or whose
behavior changes) depending on compile time build settings (Debug, Release,
DisableReplacement).
In the standard library we can now write one assert function that uses this
builtin function to provide different compile time selectable runtime behavior.
Example
Assert.swift:
@transparent
func assert<T : LogicValue>(
condition: @auto_closure () -> T, message: StaticString = StaticString(),
// Do not supply these parameters explicitly; they will be filled in
// by the compiler and aren't even present when asserts are disabled
file: StaticString = __FILE__, line: UWord = __LINE__
) {
// Only in debug mode.
if _isDebug() {
assert(condition().getLogicValue(), message, file, line)
}
}
AssertCommon.swift:
@transparent
func _isDebug() -> Bool {
return Int32(Builtin.assert_configuration()) == 0;
}
rdar://16458612
Swift SVN r16472
This commit also enables constant propagation in the performance
pipeline.
Since we are close to WWDC, this commit purposefully minimally touches
the pass (despite my hands wanted to refactor it so bad) just enough so
that we get the desired result with minimal in tree turmoil.
rdar://16604715
Swift SVN r16388
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
In the long term we want more detailed configurability of runtime checks, but for our short-term performance work we just want a blanket on/off switch. Add a StripRuntimeChecks SIL pass that, as a start, converts invocations of checked overflow builtins to the equivalent unchecked builtins and kills cond_fails. Expose it through the compiler with a -disable-all-runtime-checks switch.
NB: I haven't tested building the stdlib or running the tests with the switch thrown yet.
Swift SVN r12379
In nongeneric contexts, or contexts where we only care about the indirectness of parameters or have already substituted the generic parameters for a function, the interface types are interchangeable, so just switch over.
Swift SVN r12044
