o individual elements are not (yet) dead-strippable on LLVM though,
there doesn't seem to be a way to encode the necessary information
in LLVM (so e.g. all resource strings from a unit are currently
always linked in if at least one is referenced)
git-svn-id: trunk@32802 -
o reduces the size of the generated LLVM IR, but mainly important for LLVM
intrinsics such as llvm.memcpy.*(), as llc complains if some of their
parameters are not constants (you could work around it by first running
opt or by using clang with optimizations so that the constants, which
were loaded in registers until now, were propagated to the intrinsics
by the time llc saw them)
git-svn-id: trunk@32776 -
than the one we use to construct the LLVM equivalent (which doesn't support
variants), or in case the complete record is not defined in the source and
has to be padded with zeroes
o we do this by creating a new recorddef in this case with as elements the
defs of the actually emitted constant data, and replacing the original
def with this new def; note that this can also replace arrays in case of,
e.g., an array of a variant record type
o the pass in llvmtype takes care of inserting type conversions (bitcasts)
when these constants are accessed using the original def
git-svn-id: trunk@32719 -
def representing that string type, instead of using p(wide)char
o these string types are represented the same in llvm as p(wide)char,
but this way we can check whether the emitted data type matches the
expected one in the future
git-svn-id: trunk@32715 -
o while in principle LLVM can layout those the same as we do, this would
require special treatment in case some fields are not initialised in
a typed record declaration (because then we have to emit padding only
for the skipped fields, and not for any padding between them)
o exception: records we create to represent parameters, as those have to
match the ABI definitions exactly for them to be treated as expected
git-svn-id: trunk@32714 -
* use those field names when loading their addresses in
thlcgllvm.a_load_ref_cgpara()/gen_load_cgpara_loc(), instead of
assuming the field indices in the llvm representation of those
records matches the parameter location order (it currently does
because we let llvm lay out C-packed records, but that will
change)
git-svn-id: trunk@32713 -
as bytes in the LLVM type, so typecast them to the correct type (which is
the size that will be used by hlcg.a_load*subsetref*)
git-svn-id: trunk@32565 -
a pointer to a vmt, but a pointer to a pointer to vmt (mantis #29086)
o also adjusted the llvm type for interfaces accordingly
git-svn-id: trunk@32530 -
if the it's an addn/subn. For comparisons, the resultdef is boolean, and
left and right will already have the same type (with addn/subn, one could
be a pointer and the other an integer)
git-svn-id: trunk@32523 -
dbg_state is not sufficient to determine whether or not a def has
already been processed or not -> use stab_number (and reset it)
o also record all defs we don't emit "type" instruction for, but which
we still process to find other defs, so we reset those too
git-svn-id: trunk@32520 -
because the names we assign to parameter locations are no longer valid after
a module has been compiled (they are tasmsymbols), and they're not necessary
for declarations either; this also avoids generating calleeside parameter
information for imported routines just to write the external declaration
(the callerside information will already be available from when the routines
were called)
git-svn-id: trunk@32518 -
afterwards use hlcg.gen_load_cgpara_loc() to convert it to the Pascal
level tdef (and otherwise we try to do this twice). For non-Pascal
level calls, the code generator will automatically convert the
type if necessary when using the function result location, because
its def is (now) set to llvmretdef
git-svn-id: trunk@32475 -
they exist even if we try to read them before writing to them (e.g.
because they represent the uninitialised function result of an
inlined function)
git-svn-id: trunk@32465 -
