These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
threaded into IRGen; tests to follow when that's done.
I made a preliminary effort to make the inliner do the
right thing with try_apply, but otherwise tried to avoid
touching the optimizer any more than was required by the
removal of ApplyInstBase.
Swift SVN r26747
As part of this, re-arrange the argument order so that
generic arguments come before the context, which comes
before the error result. Be more consistent about always
adding a context parameter on thick functions, even
when it's unused. Pull out the witness-method Self
argument so that it appears last after the error
argument.
Swift SVN r26667
Provide a special single-ObjC-refcounted type info for error existentials, and lower the existential box instructions to their corresponding runtime calls.
Swift SVN r26469
- Rename getParentPattern() -> getParentPatternBinding(), since
it returns the pattern binding, not the pattern.
- Introduce new getParentPattern()/getParentInitializer() methods,
covering the most common uses of getParentPatternBinding().
NFC.
Swift SVN r26175
TerminatorInsts. Now you can walk over the successor list of a terminator
and actually modify the SILSuccessor directly, allowing better CFG
transformations. NFC.
Swift SVN r26140
come up when pattern matching on optional. Instead of expanding to a
switch with a default and one case, expand to an icmp and condbr.
Swift SVN r26090
It can be enabled with the -num-threads <n> option.
Without this option there should be NFC.
When enabled, the LLVM IR is split into multiple modules: one module for each input file.
And for each module an output file is generated. All output files must be specified with -o options:
for each input file in the command line there must be an -o <outputfile> option.
LLVM compilation is performed on each module separately.
This means that the generated code is different than with regular -wmo.
But performance and code size should be approximately the same because important inter-file
optimizations are already done at SIL level (e.g. inlining, specialization).
There is still no support in the driver for this feature.
Swift SVN r25930
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
Insert a block's context argument into the normal parameter set before lowering external arguments, instead of adding it later in a post-pass, so that we assign argument attributes to the correct indices. Fix signature expansion to put the block context parameter in the right place relative to struct returns. Fixes rdar://problem/20035272.
Swift SVN r25763
rdar://problem/19701613
Code size reductions (negative means less code size):
bin/PerfTests_O: -3.7%
bin/PerfTests_Ounchecked: -1.9%
bin/PerfTests_Onone: +0.2%
stdlib/core/macosx/Swift.o: -2.2%
The -2.2% in Swift.o constitutes of about +5% in specializations and -11% in protocoll witnesses in the dylib.
(-> still room for improvement regarding specializations)
Note that completely disabling inlining into thunks (even small functions) would increase the code size.
There is litte change in performance, a few + and - within 10%.
Beyond this there is (+ means faster):
Phonebook@O: +26%
ImageProc@Ounchecked: +14%
StringWalk@Ounchecked: -16%
Swift SVN r25001
was incomplete; we do use it on i386 for arbitrary small
aggregates, and unfortunately this means we have to learn
how to expand quite a lot of types.
Tested by the i386-simulator build. I still think
we can completely remove this code relatively soon.
Swift SVN r24981
Specialization can introduce 'A as! B' casts between unrelated types A and B, and we're not always smart enough to fold them away to a failure. We shouldn't crash in IRGen when we see them. Fixes rdar://problem/19544667.
Swift SVN r24971
the C calling convention.
You might notice the absence of tests. Older versions of Clang
used Expand for ARM64 homogeneous aggregates. Trunk Clang no
longer does this, and indeed, on Apple platforms we no longer
use Expand to pass any kind of argument at all. The only target
in trunk that uses it is the Windows target's vectorcall
alternative CC, which I have no way to convince Swift to
generate a call against. Therefore this code is completely
dead in trunk, and thus untestable.
Removing Expand completely from Clang would be the ideal solution,
but that's politically tricky because this is a part of Clang
that's frequently edited by people supporting out-of-tree backends.
I've started the process, but until then, if we're going to have
dead code, it ought to at least be correct dead code.
This commit fixes rdar://19199427, or at least it will
when it's merged to branches that actually use Expand.
Swift SVN r24949
Reapply commit r24722.
The original commit did not break the build. There appears to be an issue in
CoreAutomation (an iOS test failed with empty output). Follow up builds with
the original commit in succeeded.
Also apply Dimitri's patch to make the test condfail.sil portable.
Original message:
This significantly improves debugging experience as failures such as overflow
can be mapped back to a source line.
Code size impacts I measured on PerfTestSuite and libswift*.dylib was
neglectable.
__text section size increase:
0.24% bin/PerfTest_O
0.01% bin/PerfTest_Onone
0.20% libswift*.dylib
rdar://19118593
Swift SVN r24725
This significantly improves debugging experience as failures such as overflow
can be mapped back to a source line.
Code size impacts I measured on PerfTestSuite and libswift*.dylib was
neglectable.
__text section size increase:
0.24% bin/PerfTest_O
0.01% bin/PerfTest_Onone
0.20% libswift*.dylib
rdar://19118593
Swift SVN r24722
Until now, we treated all value parameters as +1, and all indirect parameters as +0 by reference, which is totally bogus. Now that we'll be partially applying guaranteed parameters, for instance to implement SomeType.foo curried method references, we need to get this right.
This breaks curries that capture dependent-layout parameters by value, but they were already broken due to us treating them as 'inout' captures. I'll fix this by adding NecessaryBindings and NonFixedOffsets to HeapLayout next.
Swift SVN r24475
patterns.
<rdar://problem/19184859> Swift methods defining closures that capture self in the "in" clause end up with two "self" variables in the debug info
Swift SVN r24461
emitValueCaseTest/emitIndirectCaseTest implementations when testing for
one case. This leads to dramatically better IRGen for optional (among other
things). For example, for:
class C{}
var x : C?
if let a = x {
}
we used to produce:
%15 = load i64* %14, align 8
switch i64 %15, label %16 [
i64 0, label %17
]
; <label>:16 ; preds = %entry
br label %select_enum
; <label>:17 ; preds = %entry
br label %select_enum
select_enum: ; preds = %17, %16
%18 = phi i1 [ true, %16 ], [ false, %17 ]
br i1 %18, label %22, label %19
now we produce:
%15 = load i64* %14, align 8
%16 = icmp eq i64 %15, 0
%17 = xor i1 %16, true
br i1 %17, label %21, label %18
Hopefully this makes a measurable improvement in the -O0 performance tests, but
I didn't check.
This resolves:
<rdar://problem/19404937> select_enum/select_enum_addr should generate select in obvious cases [-O0 performance]
Swift SVN r24366
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
This commit repplies r24305 with two fixes:
- It fixes the computation of spare bits for unusual
integer types to use the already-agreed-upon type
size instead of recomputing it. This fixes the
i386 stdlib build. Joe and I agreed that we should
also change the size to use the LLVM alloc size
instead of the next power of 2, but this patch
does not do that yet.
- It changes the spare bits in function types back
to the empty set. I'll be changing this in a
follow-up, but it needs to be tied to runtime
changes. This fixes the regression test failures.
Swift SVN r24324
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
Swift SVN r24305
memory layout and add a SelectInst API that allows for one to access select inst
operands when one does not care about what the cases actually are.
Previously select_enum, select_enum_addr had the following memory layout:
[operands], [cases]
In constrast, select_value had the following layout:
[operand1, case1, operand2, case 2, ...]
The layout for select_value makes it impossible to just visit operands in a
generic way via a higher level API. This is an important operation for many
analyses such as AA on select insts.
This commit does the following:
1. Adds a new abstract parent class for all select instructions called
SelectInst.
2. Adds a new templated implementation parent class that inherits from
SelectInst called SelectInstBase. This handles the complete implementation of
select for all types by templating on CaseTy.
3. Changes SelectEnumAddrInst, SelectEnumInst, SelectValueInst to be thin
classes that inherit from the appropriately specialized SelectInstBase.
I left in SelectEnumInstBase for now as a subclass of SelectInstBase and parent
class of SelectEnum{,Addr}Inst since it provides specific enum APIs that are
used all over the compiler. All of these methods have equivalent methods on
SelectInstBase. I just want to leave them for a later commit so that this commit
stays small.
Swift SVN r24159
storage for arbitrary values.
A buffer doesn't provide any way to identify the type of
value it stores, and so it cannot be copied, moved, or
destroyed independently; thus it's not available as a
first-class type in Swift, which is why I've labelled
it Unsafe. But it does allow an efficient means of
opaquely preserving information between two cooperating
functions. This will be useful for the adjustments I
need to make to materializeForSet to support safe
addressors.
I considered making this a SIL type category instead,
like $@value_buffer T. This is an attractive idea because
it's generally better-typed. The disadvantages are that:
- it would need its own address_to_pointer equivalents and
- alloc_stack doesn't know what type will be stored in
any particular buffer, so there still needs to be
something opaque.
This representation is a bit gross, but it'll do.
Swift SVN r23903
It avoids generation of llvm phi nodes with identical predecessors and differing values.
This change replaces my previous fix of this problem in r23580, where I handled it in IRGen.
There were some discussions about it with the conclusion that it's better to just disallow such cond_br instructions in SIL.
It makes the life easier for some SIL optimizations which can't deal with cond_br with identical destinations.
The original radar is <rdar://problem/18568272> Swift compiler fails with "PHI node has multiple entries for the same basic block with different incoming values!"
Swift SVN r23861
Using the intrinsics is obnoxious because I needed them
to return Builtin.NativeObject?, but there's no reasonable
way to safely generate optional types from Builtins.cpp.
Ugh.
Dave and I also decided that there's no need for
swift_tryPin to allow a null object.
Swift SVN r23824
or pointer depends on another for validity in a
non-obvious way.
Also, document some basic value-propagation rules
based roughly on the optimization rules for ARC.
Swift SVN r23695
Phi nodes may not have identical predecessors and differing values.
This should fix <rdar://problem/18568272> Swift compiler fails with "PHI node has multiple entries for the same basic block with different incoming values!"
Swift SVN r23580
variable part of the function prologue by omitting its location.
Fixes <rdar://problem/18989457> Xcode 6.2 6C86C (lldb-320.4.157) : po self returns error: Execution was interrupted, reason: EXC_BAD_ACCESS
Swift SVN r23569
Make it easier to get the "do I expect null ProtocolConformance* pointers" logic right. Audit existing uses of is<ArchetypeType>() for this purpose.
Swift SVN r23479
They don't need storage because they're empty, so we don't emit their offsets, but we still emitted references to their offset variable. Fix this by lowering ref_element_addr to an undef for empty fields.
Swift SVN r23317
