those will never call a nested routine using Pascal-level support
for accessing local variables (even if the nestedvars stayed empty,
this caused a stack frame to be allocated because a temp of 0
bytes is rounded up to 4 bytes)
git-svn-id: trunk@32739 -
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 -
aggregate to a (new) recorddef
o the size of the original type and that of the record must match
o will be used by the LLVM generator in case of a variant record, or
an array of variant records with constant data that does not match
our canonical LLVM definition
git-svn-id: trunk@32718 -
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 -
will need this for LLVM to determine whether the emitted data completely
matches the definition (if not, we have to create a def for the actual
data)
- removed no longer used fieldoffsets property
git-svn-id: trunk@32712 -
* use Pascal implementations instead of assembler for DoMethodA, DoSuperMethodA and DISPATCHERARG
* the above fixed trasing of register r31 in DoMethodA and DoSuperMethodA
* these implementations might not be that optimal, but easier to understand and more maintainable on the long run
* depends on the newly added EmulHandle stuff in exec
* use const arguments for array of ... stuff where possible
git-svn-id: trunk@32701 -
