Uses the freeze instruction available in LLVM 10.0+. If we don't freeze undef/
poison values before using them in a calculation (even if that calculation is
something like "and 0", which masks the result completely), the result will
still be undef/poison and will keep propagating.
Note that not all symbols are covered yet, because absolutevarsyms are not
yet supported and those are e.g. used for function result aliases.
Additionally, not all types are fully supported yet.
even when it's the same as the stack alignment (it can also refer to the
alignment of the data pointed to by pointer parameters)
git-svn-id: branches/debug_eh@41729 -
store tai in them
+ support for direct symbol parameters to llvm routines (without first
loading them into register)
o needed to pass such symbols to llvm intrinsics
git-svn-id: branches/debug_eh@40414 -
spilling, but we may need the type to insert bitcasts)
* load the la_catch symbol operand with loadref instead of loadsymbol,
as the latter sets refaddr_full and with llvm we use that to indicated
symbol names of named registers rather than data symbols (which in turn
prevents it from being processed for inserting bitcasts if necessary)
git-svn-id: branches/debug_eh@40412 -
tasmdata.DefineAsmSymbol() and all routines that call it
o will be used to automatically generate AB_INDIRECT sybols when
necessary
git-svn-id: trunk@34164 -
(e.g. an empty record): return an "undefined" instance of the result
type (since it's empty, its contents are irrelevant). Before, we
returned "void", but that means returning nothing rather than returning
something empty (part of fixing test/tnoext4 for llvm)
git-svn-id: trunk@34119 -
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 -
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 -
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 -
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 -
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 -
