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 -
a bitcast that reads from and writes to the same register doesn't
work well
* changed pointerdef parameters of g_ptrtypecast_reg()/ref() to regular tdef
so that these routines can also be used with procvardefs (which are pointers,
but not pointerdefs), except for the fromdef of g_ptrtypecast_ref() as this
one has to call a_loadaddr_ref_reg() (which needs the pointeddef, and getting
that is not possible for non-pointerdefs)
git-svn-id: trunk@32417 -
only required when calling a routine that returns a procvardef or
if it's a C-style varargs routine, but it's always allowed and
always doing it simplifies procvar handling
git-svn-id: trunk@32416 -
thlcgobj.g_set_addr_nonbitpacked_field_ref() and adjusted it so that
it also works for objects/classes (if the incoming reference points
to the start of the class contents)
o factored out the related code from tllvmsubscriptnode
git-svn-id: trunk@32411 -
