I've previously missed this part when moving to the DMD output filenames.
LDC used to enforce the target object file extension for all produced
objects.
So in `compilable/ldc_output_filenames.sh`, we tried to produce the object
file `myObj.myExt.` instead of `myObj.myExt`. The tests passed on Windows,
but failed at least on Linux.
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().
DMD does too, and the front-end's FileName class expects backslashes in
some places.
Due to the import and lib directories in the ldc2.conf file being
specified with forward slashes, most paths produced by LDC used both
slashes, e.g., `C:/LDC/ldc/runtime/druntime/src\object.d`, which looks
unprofessional, is problematic for the front-end and leads to differences
wrt. DMD when outputting module dependencies etc.
This reduces the size of a statically linked Phobos-based
Hello World by 11 kB on Linux x86_64.
Also creates a header file for gen/module.cpp, which has been
renamed to "modules" such as not to conflict with the frontend
header file.
LLVM's ParseCommandLineOptions() expands response files automatically, but
always uses the TokenizeGNUCommandLine tokenizer, which apparently eats
backslashes.
The solution is to pre-expand the response files into the arguments vector
on the LDC side, and using TokenizeWindowsCommandLine if LDC is built for
Windows.
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.
Notably, the glue layer side of the changed multiple interface
inheritance layout (DMD a54e89d) has not been implemented yet.
This corresponds to DMD commit 3f6a763c0589dd03c1c206eafd434b593702564e.
