* WIP: Objective-C support
* Further work on implementation
* ObjC dynamic cast
* Add swift stub class attribute
* Classes, protocols and ivars
* Fix compilation issues
* Fix objc ir codegen
* Add objc linker option
* Add swift stub classref get ir gen
* Minor cleanup
* Fix objc link flag being added on non-darwin platforms
* Refactor objc gen
* remove use of std::nullopt
* Emit protocol tables
* Remove unused variable
* Formatting
* Fix build in release mode. Thanks for nothing, c++.
* Fix consistency
* Fix dynamic casts
* Fix tocall parentfd ref and arm msgsend call
* Make instance variables work
* Implicitly add isa pointer to objc classes.
* Fix protocol referencing & allow pragma mangle
* Fix protocol linkage
* Fix direct call support
* always generate var type for methods
* Fix test 16096a
* Fix extern ivar symbol gen, retain method decls
* Remove arm32 and x86 support
* Check method and ivar info before pushing to member list
* Make ObjcMethod info untyped.
* Make ivar and method gen more robust
* Generate optional protocol symbols
* Use bitcasting instead of creating multiple type defs
* Fix invalid protocol list struct gen
* More codegen robustness
* emit protocol table as const
* Make protocol table anon struct
* Fix callable type, generate protocol_list_t properly.
* Cast vthis to argtype
* Handle protorefs and classrefs properly
* seperate label ref and deref
* Fix method lookup
* Enable objective-c tests
* Enable objc_call_static test
* Scan both classes and protocols for method ref
* Enable objective-c tests on arm as well.
* supress objc linker warning in tests
* Fix class and protocol gen structure
* Fix objc_protocol_sections test
* ObjcMethod only get callee for functions with bodies
* Fix protocol class method gen
* Make ObjcMethod anon again
* Fix missing emit calls
* Fix classref gen
* Implement some of the requested changes
* Enable compilable tests
* Fix property selector gen, ugly hack for final funcs.
* Fix segfault in referencing fd->type
* Refactor implementation
* Fix null references in class and method lookup
* include unordered_map
* Get functionality on-par with prev impl.
* Fix super context calls
* Move -L-w flag to d_do_test and use IN_LLVM in objc.d/h
* add LDC version tag to -L-w flag
* Update CHANGELOG.md
Instead of eagerly IR-declaring all such functions in root modules
being compiled.
This might reduce compile times in some cases, and is a cheap way
to improve the situation wrt. issue #2782.
Make -linkonce-templates *not* tamper with the general template
emission algorithm anymore (so on top of default non-allinst or
-allinst modes), and keep those tweaks as experimental
-linkonce-templates-aggressive.
Compiling the druntime/Phobos unittests is only marginally slowed
down compared to the more aggressive variant (~1.5% for debug,
~2.5% for release). It does show some rough 10% increase in required
memory, but that's in line with non-linkonce-templates.
The more aggressive variant has the advantage of skipping
needsCodegen() and potentially codegen'ing less symbols. The problem
is that if an instantiated symbol isn't explicitly referenced, for
instance a CRT ctor, it might not be codegen'd at all.
I.e., *define* templated symbols in each referencing compilation unit
when using discardable linkonce_odr linkage, analogous to C++.
This makes each compilation unit self-sufficient wrt. templated symbols,
which also means increased opportunity for inlining and less need for
LTO. There should be no more undefined symbol issues caused by buggy
template culling.
The biggest advantage is that the optimizer can discard unused
linkonce_odr symbols early instead of optimizing and forwarding to the
assembler. So this is especially useful with -O to decrease compilation
times and can at least in some scenarios greatly outweigh the
(potentially very much) higher number of symbols defined by the glue
layer.
Libraries compiled with -linkonce-templates can generally not be linked
against dependent code compiled without -linkonce-templates; the other
way around works.
I.e., not in their owning CU if unused therein, but in all referencing
CUs instead, as linkonce_odr. The special member functions are still
only and unconditionally emitted in the owning CU.
Analogous to ClassInfos, incl. normal linkage (external for non-
templates, weak_odr for templates).
This enables to get rid of frontend logic wrt. whether to add
TypeInfoStructDeclarations to a module's members tree - previously,
it was defined as linkonce_odr in the owning module and each referencing
module (unless speculative) - and related extra semantic and codegen for
the special member functions.
I've gone a bit further and moved the entire TypeInfo emission for LDC
to the codegen layer; no TypeInfoDeclarations are added to the module
members anymore. Whenever we need a TypeInfo symbol during codegen, it
is declared or defined, and we don't need to rely on brittle frontend
logic with speculative-ness complications.
This might slightly increase compilation speed due to less emitted
TypeInfos and functions (possibly less work for the linker too).
A slight drawback is that the job of stripping unused struct TypeInfos
is fully delegated to the linker, as the TypeInfo is guaranteed to end
up in the owning object file due to no linkonce_odr.
Another theoretical drawback is that the optimizer can definitely not
inline xtoHash/xopEquals/xopCmp/xtoString/xdtor[ti]/xpostblit function
pointer indirections in non-owning CUs without LTO (neither the pointers
nor the special member functions are defined anymore).
These (public) members are probably hardly used directly though, and
instead used by the virtual TypeInfo_Struct methods equals/compare/
getHash/destroy/postblit, which are exclusively defined in druntime's
object.o (incl. the TypeInfo_Struct vtable) and aren't cross-module-
inlined anyway (without LTO).
Re-emitting the struct TypeInfos (and optionally the special member
functions too) into each referencing CU could be handled in our codegen
layer, which should be much simpler and more robust than the upstream
scheme.
With the new available_externally emission into each referencing CU, the
enforced regular emission from the module members tree shouldn't be
required anymore.
After adapting the codegen/inlining_templates.d lit-test accordingly (no
IR definitions anymore in .ll file, because available_externally doesn't
make it there), I've noticed that a lambda in imported and inlined
call_enforce_with_default_template_params() wasn't emitted - it got
culled by alreadyOrWillBeDefined().
Function/delegate literals aren't culled anymore.
Incl. getting rid of the dependence on an associated
TypeInfoStructDeclaration, which was only really needed for the mangled
name of the global.
Also slightly revise metadata generation.
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.
As RTInfoImpl contains unsupported global variables.
`object.RTInfo` is automatically instantiated by the front-end for each
aggregate starting with v2.085, incl. the special structs in the
`ldc.dcompute` module (representing pointers), so that dcompute was
basically totally broken.
Resolves#3009.
For -betterC and/or a minimal object.d without TypeInfo:
* Skip TypeInfo emission for classes and interfaces.
* Emit null as first vtable member.
Makes dmd-testsuite's {compilable,runnable}/minimal2.d work.
Don't attempt to emit the TypeInfo for each struct declaration. We skip
the IR emission later on for betterC anyway, but starting with 2.079,
the frontend emits an error when invoking genTypeInfo() in betterC mode.
