New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-betterC #2365
-betterC #2365
Conversation
gen/runtime.cpp
Outdated
global.params.targetTriple->isOSDarwin() | ||
? llvm::ArrayRef<Type *>({voidPtrTy, voidPtrTy, uintTy, voidPtrTy}) | ||
: llvm::ArrayRef<Type *>({voidPtrTy, voidPtrTy, uintTy}), | ||
{}, Attr_Cold_NoReturn); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess adding nounwind
would be appropriate?
Edit: added.
Wrt. the TypeInfos to be omitted for While thinking about this, I seemed to recall reading on the forum that GDC handles things differently, only emitting the TypeInfos 'on-demand', so that people don't necessarily need to resort to I haven't looked at the ClassInfos yet. |
I'm nowhere near the end of this rabbit hole, but I gave up on skipping the TypeInfo emission in the declaring module for now, as redundant TypeInfos in other objects still depend on the struct's init symbol, which is only emitted in the declaring module etc. That's the case for I guess there was a historic reason for building extra 'typeid(...)' LL types for the TypeInfos, similar as the custom types for the init symbols which I got rid of not too long ago, but I found none that justifies them any longer, only complicating stuff and uglifying the IR due to more overall types and pointer bitcasts. Issue #2357 is fixed by the 5th commit - at least the module can be compiled without issues; not sure if that ClassInfo is really defined in another object so that linking will succeed with Debian's separate-compilation-setup. |
Oh please don't tell me the reason for the 'typeid(...)' types were opaque structs. I hoped to get away by skipping their TypeInfo definition, but Edit: Extended to a full dummy |
5a156e4
to
73321b4
Compare
Analogous to DMD.
Instead of druntime's _d_assert[_msg], _d_arraybounds and _d_switch_error. Tested by dmd-testsuite's runnable/cassert and compilable/betterCarray.
There's a functional change here: previously, the direct calls to `TypeInfo...Declaration_codegen()` bypassed the check whether the TypeInfo can be omitted due to the described type being speculative, which is performed for normal `Declaration_codegen()` calls only. The latter is used by `DtoTypeInfoOf()`.
Use the real LL type representing the TypeInfo (sub)class directly and from the beginning, i.e., already for the declaration, instead of building an extra LL struct type (firstly opaque, then finalized when defining the TypeInfo via RTTIBuilder). To get this to work in all cases, the dummy TypeInfo for opaque structs is now a complete TypeInfo_Struct, with all 11/13 fields zero- initialized. Previously, it was a special TypeInfo (no extra TypeInfo_Struct fields) with TypeInfo_Struct vtable, something which DMD also emits. Also refactor the RTTIBuilder finalize() interface - e.g., don't set the linkage there (had to be reverted for ModuleInfos) and only take the global variable to be defined. Cast the field initializers if required, e.g., null pointers to appropriately typed function pointers for TypeInfo_Struct etc.
No description provided.