References to dllimported globals in static data initializers lead to
undefined-symbol linker errors. We need to resolve the indirection
manually at runtime.
I went with an extra LLVM pass for Windows targets when using
`-fvisibility=public`, and scanning the initializers of all global
variables (well, only thread-global ones). The problematic pointers in
the initializers are nullified and initialized at runtime early via a
CRT constructor (working with -betterC as well).
People use `dflags "-enable-cross-module-inlining" platform="ldc"`
in their dub.sdl files; default and debug builds without -O thus
incur a superfluous compile-time cost for no benefit.
Which supports more cmdline options in the meantime than what we have
been supporting manually, and should be future-proof, similar to
InitTargetOptionsFromCodeGenFlags().
Attributes are only set if explicitly specified in the cmdline (and not
already present in the function's existing attributes).
This started out as a workaround for not being able to determine whether
the user has explicitly set -frame-pointer in the cmdline with LLVM 11,
and ended with having to touch more than I wanted. An *enabled*
-ffast-math flag (from us, not LLVM) overriding LLVM's
-enable-unsafe-fp-math, but e.g. -ffast-math=false NOT overriding was/is
one of the quirks.
By letting LLVM set up the inlining params (taking into account
`-inline-threshold`) instead of hardcoding them.
The old hardcoded thresholds were identical to the LLVM 3.9 defaults, but
they changed in LLVM 4.0:
* optLevel > 2: 275 => 250
* -Os: 75 => 50
* -Oz: 25 => 5
Apparently also fixes issue #2161.
Simplify LDMD quite a bit by translating the few different command-line
options directly in-place. This puts some more stress onto LDC's
command-line parsing, especially due to multiple occurrences of a single
Boolean option (e.g., '-o-') or mixtures of `-m64` and `-m32` etc. for
dmd-testsuite.
Also add new command-line option `-verrors-spec` showing gagged errors
(DMD's equivalent is `-verrors=<spec|limit>`) and sync the usage text with
DMD. LDMD now also recognizes `-h` (and `/?` on 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.
This PR removes the command line option which adds the pass names as additional
command line options. This code prevents compiling for AArch64 (since LLVM 3.7)
and ARM (since LLVM 3.8). Recommendation on LLVM list was to use the PassNameParser
only in test tools but not in a production compiler.
It has been a long time since this actually caused problems. If some
start to show up again, we should preferrably come up with a local fix
instead of globally disable everything (which is horrible for -O3 -g
builds).
This approach is easier and requires less code. With some template foo
the BoolOrDefaultAdapter is not required.
This solutions applies to previous LLVM versions, too.
