Don't perform a vtable lookup for those, resolve them directly instead.
Fixes issue #1450, where calling the base method in the overwritten
method resulted in an infinite loop and corresponding stack overflow.
* Introduce a DRValue base class to be able to discriminate between
DLValues and DRValues (e.g., function parameters).
* Let DValue::getRVal() return each DValue's value as DRValue.
This allows to convert a DLValue to a DRValue, a snapshot of the
lvalue's current state, while retaining the D type, something we've
previously lost when returning the low-level rvalue directly.
* Let the DtoR/LVal() helpers be the only way to convert a DValue to a
low-level value.
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.
All DValues are now required to have a (main) LL value, which allows
to conveniently refactor the DValue hierarchy.
DSliceValue now represents a LL struct instead of separate values for
length and pointer.
Use the existing public field directly instead.
It's shorter and different than LLValue's getType() (making it easier
to discriminate DValues and LLValues for experienced LDC devs imho).
DSliceValue is still a special case and contains pointer and length
separately, which are packed to a LL struct in getRVal().
It'd probably pay off to do it the other way around and store the LL
struct as single value and allowing for access to the components.
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.
When certain attributes are applied to the calling function, like "unsafe-fp-math", the inlined inlineIR function has to have the same attributes otherwise the calling function attribute will be reset to the safe merge of the two: "false". Because the same inlineIR function can be called in different functions using an alias definition, a new function (with possibly different attributes) has to be instantiated upon every call.
Related GH issue #1438
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.
This should put an end to the "instruction does not dominate all uses"
ICEs triggered by the new cleanup code, such as GitHub #1294 and other
reports before that.
The root cause was that the code assumed that DVarValues were always
either globals or pointed to allocas in the function entry basic block,
whereas DVarValue is really just a generic lvalue.
The semantics (hidden pointer to values) are the same, so it makes
sense to reuse the associated code. Delaying the load to wherever
the variable is actually used might make for somewhat more efficient
codegen.
Incidentally, this fixes GitHub #1294, but that is more a case
of the underlying bug not being triggered anymore by that
particular test case.
The relationship between them is at best tenuous; DVarValue should
probably be renamed to DLValue and is used right now to describe
a general lvalue, of which variables are just one example.
This is in preparation of removing it entirely. In the contexts
where it was used, the information about the variable declaration
was directly available anyway. Instead, we now use the AST directly
like the DMD glue code does.
