add such symbols to the pseudo-arrays llvm.compiler.used or llvm.used
depending on their nature (fixes compiling Objective-C programs with
optimization, and keeps the FPC ident in the linked binary)
git-svn-id: trunk@35041 -
typed constant does not match the equivalent LLVM definition (it's only
used to check whether any emitted data's type differs from the LLVM
definition's field types)
o fixed a potential out-of-bounds access related to this: the index of the
equivalent LLVM field kept getting increased and at some point we checked
whether the current emitted data's type was different from the LLVM field
type without verifying first that the LLVM equivalent field index was not
yet beyond the number of LLVM equivalent fields
git-svn-id: trunk@35018 -
const builder, it can only initialise the function pointer part of the
complex procvar -> convert the to-size to an address-only version of
the complex procvar to avoid us trying to bitcast an address into a
record containing both the function and self/nestedfp pointer
(fixes test/tmaclocalprocparam4e for llvm)
git-svn-id: trunk@34118 -
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 -
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 -
indicate symbols that should never be removed by the linker
o TODO for llvm, needs support for the @llvm.used array (only used for
the compiler ident, so it's not that important
git-svn-id: trunk@31677 -
typed const builder, for use when e.g. emitting a table preceded by
the number of elements in case that number is only known afterwards
git-svn-id: trunk@31648 -
defined) or a declaration (external symbol), instead of deriving it from
from the bind of the tasmsymbol. The reason is that with module-level
inline assembly, some locally implemented functions (in pure assembler)
won't have an LLVM IR body
git-svn-id: trunk@31629 -
implicitly taking the address of a complex expression in a typed constant
(you cannot put the contents of another memory location in a typed
constant)
git-svn-id: trunk@31252 -
bytes,becayse if we emit them at the end then we may interpret the first
padding byte as the final component of the queued expression
git-svn-id: trunk@31246 -
index of the corresponding llvm fieldvar, as this index is a member
of the fieldvarsym that only gets initialised once the llvm shadow
symtable gets built, which in turn is triggered by trying to access
it for the first time -> if fieldvarsym.llvmfieldnr got loaded by
the compiler before evaluating the llvmst expression and if the
llvmst hadn't been built yet, this llvmfieldnr was not yet initialized
git-svn-id: trunk@31060 -
handle recursive record references (rec= record prec: ^rec)
o llvm unfortunately does not support recursive references to array types
or function pointers, so those will currently still result in endless
recursion when the compiler tries to write them out. Solving those
will require a lot of typecasting in the generated code
git-svn-id: trunk@30675 -
get_final_asmlist() to the constructor, in preparation of supporting the
creation of internal builders for local data that will ignore some of the
irrelevant flags (at creation time)
git-svn-id: branches/hlcgllvm@30334 -
ttai_typedconstbuilder.emit_string_offset() so it can also be used outside
the context of parsing a Pascal-level typed constant
git-svn-id: branches/hlcgllvm@30111 -
records is only known once we have completely parsed all of their data
(the alignment of a record depends on the alignment requirements of its
field with the largest alignment) -> only insert the padding bytes after
completely parsing them
git-svn-id: branches/hlcgllvm@28765 -
