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 -
a code and temp generator for the architectural target instead of for LLVM
* write the code for pure assembler routines using a GNU-style external
assembler writer for the target, with a decorator to wrap it in
LLVM module-level assembly statements
git-svn-id: trunk@31633 -
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 -
that we can use assembler writers with different conventions from the
currently set target_asm (e.g. an x86 assembler writer for inline assembly
in LLVM IR)
git-svn-id: trunk@31628 -
labels of LOC_JUMP in the node's location. This generates some extra jumps
for short circuit boolean and/or-expressions if optimizations are off, but
with optimisations enabled the generated code is the same (except for JVM
because the jump threading optimisation isn't enabled there yet).
git-svn-id: trunk@31431 -
intrinsic. This may insert actual calls to a function called memcpy with
the signature of the libc function, but llvm optimizers are free to
insert such calls by themselves already. This means that for non-libc
targets, we will have to add weak symbols for memcpy/memmove/memset
that call through to move/fillchar when using LLVM, so that these
implementation are used when not linking to libc
git-svn-id: trunk@31408 -
o all external symbol definitions are now inserted in the llvmtype post pass
based on all declarations and types used in llvm instructions
o this means we don't have to use the workaround with the Pascal mangled
names anymore for all external names, as we now insert the external
references only once we know all type information
git-svn-id: trunk@31287 -
interface of a unit, or forward declared, and then the implementation turns
out to be external. We now properly generate a wrapper routine at the
Pascal level for the original declaration that calls through to the
external routine
git-svn-id: trunk@31285 -
linkage types for aliases (or its documentation hasn't been updated), and
external linkage is the default so it doesn't matter for earlier versions
git-svn-id: trunk@31284 -
unicodestring constants: specify the type of the pointer to the
string record (which is indirect) rather than that of the string
array (which will implicitly be the result of the getelementptr)
git-svn-id: trunk@31256 -
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 -
a single external symbol may be used with multiple declarations that
have different types:
o always declare an alias with the Pascal-mangled name that aliases the
external symbol, with the type of that Pascal declaration
o if the external symbol is not actually external but in the same unit,
we will determine the type of that symbol via its declaration and
insert type conversions in the alias declarations in case they use a
different type
o if it is external (so there is no declaration from which we can determine
its real type) and there are nevertheless multiple aliases for it with
different types, we just take the type of the first alias and insert
type conversions for the other aliases. LLVM will take care of the
conflicting types in multiple modules when performing WPO if necessary
git-svn-id: trunk@31054 -
gen_load_para_value(), as this may be different depending on
the calling conventions
* adapt llvm's gen_load_cgpara_loc() to use this passed def rather
than hardcoding the para's def (although these will normally match)
git-svn-id: trunk@31050 -