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
Currently, we use heuristics to determine if the conversion errors come from directly inlining the std integer types. However, if those operations are wrapped in another transparent function, we will not see the user-visible integer types anymore, so we fall back to Builtin types. Enhance the diagnostics in that case to specify if the sign-agnostic Builtin types are signed or unsigned.
This reverts r10484 and adds test cases.
Swift SVN r10512
Instead of hardcoding Builtin.Word to be an alias for Builtin.Int64, make it its own type of abstract pointer width.
- Change BuiltinIntegerType's width representation to accommodate abstract widths.
- In the AST and in SIL, store values of the types as the greatest supported size for the abstract width (64 bits for a pointer).
- Add some type safety to the ([sz]ext|trunc)(OrBitCast)? builtins that they're used appropriately given the upper and lower bounds of the abstract sizes they're working with.
- Now that Builtin.Word is a distinct type, give it its own mangling.
- In IRGen, lower pointer-sized BuiltinIntegerType appropriately for the target, and truncate lowered SIL values if necessary.
Fixes <rdar://problem/15367913>.
Swift SVN r10467
Add new builtins(by generalizing, renaming, and extending the builtins used for compile time integer literal checking). These new builtins truncate integers and check for overflow/truncation errors at runtime. Use these for FixedPoint conversion constructors.
Fix a routine in stdlib's String implementation and a test that relied on bitwise behavior of the constructors (and triggered overflows).
TODO:
- Teach CCP about these to get static checking.
- Add special builtins for same size signed <-> unsigned conversions.
Swift SVN r10432
tuple-producing results (like those produced by folding overflow builtins).
Before the pass would just RAUW the apply_inst with a tuple_inst, but this
would leave around a bunch of tuple extracts. Now we seek and destroy them.
This unblocks other transformations and allows the stdlib to shrink by another
1700 LOC.
Swift SVN r9900
There are no values other than instructions that can use other values. BBArguments are
defs, not uses. This eliminates a bunch of casts in clients that use getUser().
Swift SVN r9701
Instead of adding all the instructions into the WorkList to begin with,
add only the constants and try to fold their users. Each time a user can
be folded, add it to the WorkList. This keeps the WorkList smaller.
The inverted algorithm also allows to simplify the handling of struct_extract
and tuple_extract.
(as suggested by Chris in comments on r9545)
Swift SVN r9598
the algorithm looks great, I made a number of minor stylistic
and comment changes, used some simpler APIs, and simplified
some things. The only functionality change is a corner case
correctness bug where it looks like the struct/tuple extraction
folding logic in constantFoldInstruction could return the wrong
result in some corner case.
Swift SVN r9547
(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
