IRGen can introduce calls to type metadata accessors for types that
should not be visible to the current translate, which can manifest in
linker errors within a module (for references to private types when
whole module optimization is disabled) or across modules (for
references to private/internal types in another module). Introduce a
new compiler flag `-emit-public-type-metadata-accessors` that emits
all type metadata accessors with public linkage, to work around the
problem in affected projects. This flag is intended to go away once we
have a proper solution.
This bug has been around in Swift "forever", but compiling the
overlays using -enable-resilience has exacerbated the problem and
caused regressions. This is a short-term fix to
rdar://problem/40229755 while we work on the correct long-term fix.
When the supplementary-outputs file is written for an -index-file invocation it writes out the first input file
given in arguments instead of the input file that is provided by -index-file-path option. This then causes the frontend
index invocation to fail with an error because there is a mismatch in the primary input file and the input file that is written
in the supplementary-outputs file.
When generating a compiler invocation in driver::createCompilerInvocation()
we end up using filelists if the number of inputs is > 128 (to work around
command line arg limits). We never actually write them out though, and so
fail when parsing the frontend arguments that reference them.
As this function is called frequently by SourceKit and command line limits
aren't a concern here, this patch makes the 128 threshold value configurable
via a new -driver-filelist-threshold option. This is set to its maximum value
in driver::createCompilerInvocation() to ensure filelists aren't used. This
new option makes the existing -driver-use-filelists (that forces filelists to
be used) redundant as it's now equivalent to -driver-filelist-threshold=0.
Resolves rdar://problem/38231888
Adds a -working-directory option which can be used to modify how
relative paths are resolved. It affects all other paths used in driver
options (controlled by a new ArgumentIsPath flag on options) as well as
the contents of output file maps and auxilliary file paths generated
implicitly by the compiler itself.
rdar://37713856
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
Otherwise, we leave optimization opportunities on the table, and in
some cases even fail to remove marker intrinsics inserted by earlier
optimization.
Background: under -embed-bitcode, compilation happens in two stages: a
"frontend" job that compiles Swift code, generates LLVM IR, optimizes
it, and then emits a .bc file; and a "backend" job that takes that
.bc, converts it to assembly, and emits an object file with the
original bitcode embedded. However, there are actually optimization
passes that run before and during that "convert to assembly" step that
were getting completely skipped.
rdar://problem/34864094
This brings the capability from clang to save remarks in an external YAML files.
YAML files can be viewed with tools like the opt-viewer.
Saving the remarks is activated with the new option -save-optimization-record.
Similarly to -emit-tbd, I've only added support for single-compile mode for now.
In this case the default filename is determined by
getOutputFilenameFromPathArgOrAsTopLevel, i.e. unless explicitly specified
with -save-optimization-record-path, the file is placed in the directory of the
main output file as <modulename>.opt.yaml.
This allows reporting successful and unsuccessful optimizations similar to
clang/llvm.
This first patch adds support for the
options -Rpass=<pass-name-regex> -Rpass-missed=<pass-name-regex>. These allow
reporting successful/unsuccessful optimization on the compiler output for passes
specified by the regex. I've also added one missed and one passed remark type
to the inliner to test the infrastructure.
Clang also has the option of collecting these records in an external YAML data
file. This will be added in a later patch.
A few notes:
* The goal is to use this facility for both user-lever "performance" warnings
and expert-level performance analysis. There will probably be a flag in the
future differentiating the verbosity.
* The intent is match clang/llvm as much as it makes sense. On the other hand I
did make some changes. Unlike in llvm, the emitter is not a pass which
simplifies things. Also the remark class hierarchy is greatly simplified since
we don't derive from DiagnosticInfo. We also don't derive from Diagnostic to
support the streaming API for arbitrary named-value pairs.
* Currently function names are printed mangled which should be fixed.
