D2.072 apparently doesn't set the STCforeach storage class for each
special reference anymore. So let's consider all references which aren't
parameters, i.e., all locals with STCref, as special references.
By-ref parameters are different as we simply use the LL pointer parameter as
lvalue for the variable, no extra alloca required. Special references are
automatically dereferenced pointers and as such occupy a dedicated alloca for
the address.
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.
There's no <Type>_init type for aggregates (structs and classes) anymore,
effectively eliminating a *lot* of named LLVM types, some bitcasts as well
as replacements of globals etc.
To get there, it was even required to use the regular type for compatible
literals too, otherwise structs embedded as fields in other aggregates had
an anonymous type (well, the LLVM constant for the field initializer had)
and so the container initializer wasn't compatible with the regular type
anymore.
What was also necessary was a fix wrt. static arrays of bools (LLVM
constant of type `[N x i1]` vs. `[N x i8]` for regular type).
I also had to change the initializer for `char[2][3] x = 0xff` from
`[6 x i8]` to `[3 x [2 x i8]]`, i.e., NOT flattening multi-dimensional
inits from a scalar.
So only literals with overlapping (union) fields and an explicit
initializer initializing dominated non-alias union fields should still
have a mismatching anonymous type - i.e., very, very few cases.
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.
The D types of the variable and the right-hand-side of the init AssignExp
must match; this fixes issue #1548.
Don't restrict it to memory-only types anymore though; the sret-check
performed by DtoIsReturnInArg() should suffice and makes more sense to me.
* 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.
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).
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.
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
