LLVM already provides suited RAII helper types to restore the IRBuilder
state. [They sadly aren't movable, so I've had to wrap them in a
unique_ptr.]
While at it, also minimally revise debuginfo generation for functions.
Replace the stack of IRScopes, each with its own IRBuilder, by directly
tampering with the state of a single IRBuilder.
This seems like the most feasible way to account for a breaking change
in LLVM 11, disallowing IRBuilder from being copied.
Fixes#3490 by avoiding unnecessary extra key allocations for the literals cache etc.
Also gets rid of code duplication and improves IRState encapsulation.
* Extend the error message, closely following DMD. Tested by
fail_compilation/fail5634.d.
* Check across all compiled modules, not on a per-object-file basis.
That's what DMD does too.
* Apply the implicit `return 0` / void -> int return type promotion to
all D/C main functions, not just the first one. This prevents some
potential follow-up crashes.
Resolves#3245 by adding `pragma(lib, <name>)` library names to
`llvm.dependent-libraries` for ELF object files.
For Mach-O, embed appropriate linker options for `pragma(lib)` and
support generic `pragma(linkerDirective, <flag>, ...)` as well.
Tie the state to an LLVM module/object file instead of having a global
one. And finalize it once per LLVM module instead of once per D module
(previously, as part of ModuleInfo generation).
Fixes issue #2388.
Postpone the destruction of replaced global variables, register them in
`IRState::globalsToReplace` and perform a second replacement pass when
finalizing the IR module. The globals will be destroyed in that 2nd pass,
so there may still be dangling pointers in `IrGlobal::value`, but now only
after writing the module.
The nicer thing would be replacing IrGlobal::value by IrGlobal::getValue()
which could look it up in IRState, but that's not feasible due to the
field being inherited from IrVar and IrGlobal apparently quite often being
used as IrVar (via pointers union), so the cached field is currently
required.
So the feasible options to me were either registering each IrGlobal with
its mangled name and replacing their values when swapping out the global
variable, or performing this second replacement pass right before
finalizing the IR module to make sure we really replace all occurrences.
I went for the latter as it's both easier and safer (from the LL
perspective as the old global might be cached somewhere else too).
* [NFC] Make LDC somewhat aware of addrspaces.
Required so that we don't generate invalid code when dealing with pointer to addrspaces other than zero.
The missing alignment is a front-end bug; this is a combined backport
of dlang/dmd@b9aa6ed and dlang/dmd@a93fa3c.
For POSIX targets, the critical section size was assumed to be identical
to the host compiler's, which generally isn't true when cross-compiling.
DtoMutexType() wasn't used anywhere, so I removed it.
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.
Now with *almost* working EH codegen. Does not compile Phobos yet
because we run into the "instruction does not dominate all uses"
issue when an r-value result of toElemDtor is used and we need to
run cleanups in between. Should easily be fixed by promoting those
values to allocas.
Most of the changes outside of ir/irfunction.{h, cpp} are just
because CreateCallOrInvoke moved locations. I took the
opportunity to also make use of the different arg count
overloads where possible.
Never generates any landing pads or invoke instructions right now
for simplicity. The code for emitting them will be added back in
the next step.
The "after..." blocks without any precedessors remain for now, as
we need a clean way to suppress any codegen for that block (but
not new blocks, which might resolve labels) before tackling that
one.
Builds druntime/Phobos on OS X x86_64 (albeit without EH, of course).
Specifying the basic block before which to insert the new one
is not mandatory when calling llvm::BasicBlock::Create. This
was the only use of the tracked "end" block. The concept was
phony anyway because there is no single "end" to a scope with
unwinding and so on.
For prettying up the IR, it is possible to change the order
of basic blocks using move{Before, After}().
