`global.params.optimize` is never changed from its initial `false` state.
When experimentally enabling it, the MS linker produces warnings like
LINK : /LTCG specified but no code generation required; remove /LTCG from
the link command line to improve linker performance
The default MS C runtime library doesn't depend on the `LINK_WITH_MSVCRT`
CMake variable anymore.
The user can freely choose among the 4 variants libcmt[d] / msvcrt[d] via
-mscrtlib or choose between static/dynamic release variant via -static.
LDC keeps on defaulting to the static release C runtime, so
`-static=false` or `-mscrtlib=msvcrt[d]` must be used explicitly in order
to link against the runtime DLLs.
For invoking MS tools such as link.exe and lib.exe, which require
compatible PATH, LIB, LIBPATH etc.
We previously wrapped the invokation of the tool with a batch file taking
care of setting up the environment and then calling the actual tool.
I changed this to first invoke another batch file setting up its
environment and then dumping all environment variables to a file. LDC then
parses this file and updates its own environment variables. Later spawned
child processes then inherit the updated environment, and the tools will
be located by LLVM in updated PATH.
This allows LDC to keep track of the used Visual C++ installation (and
could so set up additional runtime libs required since VS 2015, something
we would have needed some time back when we still supported VS 2013). It's
also required as a prerequisite for integrating LLD as in-process linker
on Windows.
I quickly looked into the option of setting up the environment manually,
but the MS batch files are full of quirks, mixtures of registry and
file-system lookups, checking for existence of misc. headers to filter out
bogus installations etc. With VS 2017, there's nothing in the registry at
all anymore (at least for the Build Tools); MS expose a COM interface for
querying the VS installer... But at least they still provide the batch
files.
By directly integrating LLVM's `llvm-lib.exe` driver to generate static
libs for MSVC targets and a stripped-down version of the `llvm-ar` tool
for the other targets.
Introduce command-line option `-archiver=<file>` to allow the user to
specify an external archiver to be invoked.
Let LDC treat relative output paths as relative to the current working
directory again (as it always used to until a few weeks ago). It's more
intuitive and avoids breaking build systems/scripts using LDC directly.
Only LDMD continues to prepend the -od directory to the relative output
path, for DMD compatibility.
Fixes issue #1819.
Make sure the overall order corresponds to the user's command-line order
of object and source files. The only exception being singleObj builds,
for which the single object file for all source files is always the first
entry in the object files list (which is forwarded to the linker in that
order). This is done so that we can easily get hold of the name when
emitting the single object file later in the `ldc::CodeGenerator` dtor.
It should also clearly define the linking order (affecting comdat
selections etc.) for special singleObj builds.
Also reuse some more code (wrt. output filenames) from DMD's main().
Add the commandline options -fprofile-instr-generate[=filename] and -profile-instr-use=filename
-fprofile-instr-generate
-- Add instrumentation on branches, switches, and function entry; uses LLVM's InstrProf pass.
-- Link to profile runtime that writes instrumentation counters to a file.
-fprofile-instr-use
-- Read profile data from a file and apply branch weights to branches and switches, and annotate functions with entrycount in LLVM IR.
-- Functions with low or high entrycount are marked with 'cold' or 'inlinehint'.
The only statement type without PGO yet is "try-finally".
A new pragma, `pragma(LDC_profile_instr, [ true | false ])`, is added to selectively disable/enable instrumentation of functions (granularity = whole functions).
The runtime library ldc-profile-rt is a copy of LLVM compiler-rt lib/profile. It has to be exactly in-sync with the LLVM version, and thus we need a copy for each PGO-supported LLVM (>=3.7).
import ldc.profile for a D interface to ldc-profile-rt (for example to reset execution counts after a program startup phase).
The instrumentation data is mainly passed on to LLVM: function-entry counts and branch counts/probabilities. LDC marks functions as hot when "execution count is 30% of the maximum function execution count", and marks functions as cold if their count is 1% of maximum function execution count.
The source of LLVM's llvm-profdata tool is hereby included in LDCs repository (different source for each LLVM version), and the binary is included in the install bin folder.
The executable is named "ldc-profdata" to avoid clashing with llvm-profdata on the same machine. This is needed because profdata executable has to be in-sync with the LLVM version used to build LDC.
Maintenance burden: for trunk LLVM, we have to keep ldc-profile-rt and llvm-profdata in sync. There is no diff with upstream; but because of active development there are the occasional API changes.
The temporary files created should be unique for parallel processes (e.g. in a test suite where LDC is called in parallel with perhaps same input).
These files will be deleted after execution so their name is not relevant. For better linking errors, the new filenames are created by appending random characters to their name.
