This is needed for Windows which does not support cross-module data
references without indirection. By lazy initializing the data, we can
indirect through the IAT for the data pointer and fill in the parent
pointer.
This adds a mostly flow-insensitive analysis that runs before the
dominator-based transformations. The analysis is simple and efficient
because it only needs to track data flow of currently in-scope
accesses. The original dominator tree walk remains simple, but it now
checks the flow insensitive analysis information to determine general
correctness. This is now correct in the presence of all kinds of nested
static and dynamic nested accesses, call sites, coroutines, etc.
This is a better compromise than:
(a) disabling the pass and taking a major performance loss.
(b) converting the pass itself to full-fledged data flow driven
optimization, which would be more optimal because it could remove
accesses when nesting is involved, but would be much more expensive
and complicated, and there's no indication that it's useful.
The new approach is also simpler than adding more complexity to
independently handle to each of many issues:
- Nested reads followed by a modify without a false conflict.
- Reads nested within a function call without a false conflict.
- Conflicts nested within a function call without dropping enforcement.
- Accesses within a generalized accessor.
- Conservative treatment of invalid storage locations.
- Conservative treatment of unknown apply callee.
- General analysis invalidation.
Some of these issues also needed to be considered in the
LoopDominatingAccess sub-pass. Rather than fix that sub-pass, I just
integrated it into the main pass. This is a simplification, is more
efficient, and also handles nested loops without creating more
redundant accesses. It is also generalized to:
- hoist non-uniquely identified accesses.
- Avoid unnecessarily promoting accesses inside the loop.
With this approach we can remove the scary warnings and caveats in the
comments.
While doing this I also took the opportunity to eliminate quadratic
behavior, make the domtree walk non-recursive, and eliminate cutoff
thresholds.
Note that simple nested dynamic reads to identical storage could very
easily be removed via separate logic, but it does not fit with the
dominator-based algorithm. For example, during the analysis phase, we
could simply mark the "fully nested" read scopes, then convert them to
[static] right after the analysis, removing them from the result
map. I didn't do this because I don't know if it happens in practice.
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
Instead of capturing SubstGenericParametersFromMetadata and SubstGenericParametersFromWrittenArgs by value, capture by reference.
This avoids those instances to be copied and thus avoids a lot of mallocs.
SR-10028
rdar://problem/48575729
This dramatically reduces the number of needed malloc calls.
Unfortunately I had to add the implementation of SmallVectorBase::grow_pod to the runtime, as we don't link LLVM. This is a bad hack, but better than re-inventing a new SmallVector implementation.
SR-10028
rdar://problem/48575729
We would not previously symbolicate the stack trace and as a result
would not display the stack trace. Add symbolication support to the
runtime to actually make use of the captured stack trace. This allows
us to get a stack trace when the standard library or swift code reports
a fatal error.
Because Microsoft inlines the definitions of the printf family of
functions, we end up with undefined references to them. Add an explicit
request to link against the `legacy_stdio_definitions` library when
`ucrt.C.stdio` is used which provides out-of-line definitions for them.
This fixes the building of the `stdlib/VarArgs' test.
Windows uses `char *` for the `va_list` type even on x86_64. Restore
the correct selection of `__VaListBuilder` for Windows x86_64. This
partially fixes variadic functions.
These are supposed to be processed in the C locale always, irrespective
of the current locale. We were not doing this and so we would parse the
value incorrectly.
Update the shims logic to make sure that it works for Xcode as well.
Rather than adding additional rules, just simplify it down to the one
canonical way in modern LLVM land. The headers are always installed to
the LLVM_LIBRARY_OUTPUT_INTDIR which will be defined for us in both the
standalone and unified build mode. This allows us to just remove all
the work to find the headers since they will always be in one location.
We've been collecting the location info for some time now, but
apparently never printed it in no-assert builds of the stdlib, which
means this functionality was never available to the users.
With this change, the location will be printed depending on the
debug/release build configuration of the program, not stdlib.
Somewhat addresses: <rdar://problem/42980523>
The assertions here are based around the idea that `std::atomic` is
trivially constructible which is not a guarantee that the standard fully
provides. The default initialization of the `std::atomic` type may
leave it in an undetermined state. These were caught using the Visual
C++ preview runtime.
Ideally, the object constructor would use a placement new operator.
However, prior to C++17, the C++ standard mandated that there be a
NULL pointer check in the placement new operator. This is something
which is no longer the case with C++17. Switch to the placement new
operator for C++17 and newer and enable that codepath for Windows as
well (which seemingly elides the null-pointer check with clang-cl).
When compiling for a 32 bit machine, uintptr_t from ReflectionInfo will
be the integer sized to hold a 32 bit pointer, so a 64 bit pointer might
not fit.
This commit removes the solution in
0f20c486e0 and does a runtime check that
the calculated offset will fit into the target machine uintptr_t, which
might not be true for 32 bits machines trying to read 64 bits images,
which should not be that common (and those images have to have offsets
bigger than what a 32 bits number can hold).
Rather than directly using the extension `__builtin_expect`, use a macro
to permit the removal of the builtin on compilers which do not support
this (i.e. cl). This permits us to build the swift compiler with MSVC
again.
- Add an underscore to private/internal symbols
- Make access levels explicit, even when they’re implied from context
- Conform to max line length of 80 characters
- Conformances declared on separate extensions that implement them
- Arrange member declarations so that stored properties appear first
- Expand single-letter function and type parameter names where there is an obvious name that’s more descriptive
- RangeReplaceableCollection.fastApplicationEnumeration → CollectionDifference._fastEnumeratedApply
We were previously treating all the builds as shared, which is not the
case for the host library build of SwiftRemoteMirror. The warnings were
lost in the interminable spew from the build which is now fixed and this
stands out.
`-Wall` with the clang-cl interface gives us `-Weverything` effectively,
which really reduces the effectiveness of the warnings. Switch to `/W3`
which is roughly equivalent to `-Wall` in clang mode.
