are the same in case of open arrays (their size can't be determined at
compile time) -- this is just a sanity check, which can't be performed in
this case
git-svn-id: trunk@33979 -
pasbool8type for this results in too much trouble (we mustn't use i1
for parameters, because then LLVM will try to apply the ABI convention
for passing "1 bit" values, or in records because then this may
result in unwanted bitpacking). Downside: the new LLVMBool1 type is
also exposed in the system unit, because we need it to define LLVM
intrinsics...
git-svn-id: trunk@33726 -
inserttypeconv()
o keep typeconversions between structurally equivalent but semantically
different procvardefs for LLVM and JVM, because they're different
types there
git-svn-id: trunk@32904 -
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 -
