The previous check wouldn't check intermediate aggregates for static-ness,
that was one problem. The other was the assertion that the outer function
can be reached as long as there are no static functions inbetween, which
isn't always the case, as issue #1864 clearly shows, which is resolved by
this.
Compatible with DMD, but restricted to Windows and functions only.
`export` functions with bodies get the dllexport attribute and will be
exported if the containing object is pulled in when linking.
Body-less `export` functions get the dllimport attribute and will be
accessed via an import table indirection, set up at runtime by the OS.
This is a temporary solution, the proper fix is a pending DMD PR, after
which LDC will need to be adapted.
Previously, the transitory state only needed and valid during
generation of the LLVM IR for the function body was conflated
with the general codegen metadata for the function declaration
in IrFunction.
There is further potential for cleanup regarding the use of
gIR->func() and so on all over the code base, but this is out
of scope of this commit, which is only concerned with those
IrFunction members moved to FuncGenState.
GitHub: Fixes#1661.
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.
Allow ABIRewrites to return the D parameter's LL value directly.
Most rewrites store to memory anyway, so let the D parameter point
directly to that memory instead of a dedicated alloca bitcopy.
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
The first check is what DMD also does; the second one is to replace
the assertion by an ICE, since the bug can apparently be triggered
rather reliably.
See GitHub #1360.
