Sema models enum case constructors as ApplyExprs. Formerly SILGen
would emit a case constructor function for each enum case,
constructing the enum value in the constructor body. ApplyExprs
of case constructors were lowered like any other call.
This is nice and straightforward but has several downsides:
1) Case constructor functions are very repetitive and trivial,
in particular for no-payload cases. They were declared
@_transparent and so were inlined at call sites, but for
public enums they still had to be emitted into the final
object file.
2) If the enum is generic, the substituted type may be loadable
even if the unsubstituted type is not, but since the case
constructor is polymorphic we had to allocate stack buffers
anyway, to pass the payload and result at the right abstration
level. This meant that for example Optional.Some(foo)
generated less-efficient SIL than the equivalent implicit
conversion.
3) We were missing out on peephole optimization opportunities when
the payload of an indirect case or address-only enum could be
emitted directly into the destination buffer, avoiding a copy.
One example would be when an enum payload is the result of
calling a function that returns an address-only value indirectly.
It appears we had unnecessary copies and takes even with -O.
Again, optional implicit conversions special-cased this.
This patch implements a new approach where a fully-formed call to
a element constructor is handled via a special code path where
the 'enum' or 'init_enum_data_addr' / 'inject_enum_addr'
instructions are emitted directly. These always work on the
substituted type, avoiding stack allocations unless needed.
An additional optimization is that the ArgumentSource abstraction
is used to delay evaluation of the payload argument until the
indirect box or address-only payload was set up.
If a element constructor is partially applied, we still emit a
reference to the constant as before.
It may seem like case constructor functions are at least useful
for resilience, but case constructors are transparent, so making
them resilient would require a new "transparent but only in this
module, and don't serialize the SIL body" declaration.
@inline(always) is almost what we need here, but this affect
mandatory inlining, only the optimizer, so it would be a
regression for non-resilient enums, or usages of resilient enums
in the current module.
A better approach is to construct resilient enums with a new
destructiveInjectEnumTag value witness function, which is
coming soon, and the general improvement from that approach
is what prompted this patch.
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
We were leaking dealloc_stacks when the enum constructor had to create temporary allocations in order to implode address-only tuple payloads.
Swift SVN r8971
