VS has different name manglings for classes and structs. With the
new extern(C++, class) and extern(C++, struct) declarations, the
name mangling algorithm is changed to use a mangling different
from the used D entity.
A common use case is to map a value type modeled as class in C++ to
a struct in D.
This is backport of https://github.com/dlang/dmd/pull/5875.
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.
Windows x64 ABI: remove unnecessary \01 from mangled symbol name.
This removes the 0x1 byte from `.mangleof` accessible from user code.
Resolves issue #1519
Also let mangleForLLVM take a std::string, to enable C++11's moves.
The fix for 15839 (accessing this.outer from a member function
inside a nested class) in bb5f550 produces a ThisExp that
refers to the 'this' VarDecl in an outer scope, leading to the
latter being referenced from the nested scope without that being
added to its nestedRefs. Subsequently, the VarDecl is also not
present in the outer FuncDecls closureVars.
This is a weird construct, and outside the AST invariants that
would previously hold. This commit properly at least properly
registers the nested reference, but using a ThisExp in this
manner might not be the cleanest way in the first place.
This is a back-port of DMD commit a117c87a8a (#5741),
and fixes runnable/inner.d.
It was added ages ago to work around an issue with tuples not being
expanded in function arguments and/or variable declarations, but
it doesn't seem to be required anymore.
D needs to compile itself on non-x86 hosts where real type might be
something other than 80-bit extended precision. The simplest approach
is to use the existing D compiler real type as it must already have
correct real.nan and snan intializer.
Note this does not work for cross-compiling to alternate targets and is
only intended as transitional until that capability is added.
Upstream commit: a776514edc914e2e09bd4298fb07f2ac99e86f45
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.