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 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 -
* 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 -
afterwards use hlcg.gen_load_cgpara_loc() to convert it to the Pascal
level tdef (and otherwise we try to do this twice). For non-Pascal
level calls, the code generator will automatically convert the
type if necessary when using the function result location, because
its def is (now) set to llvmretdef
git-svn-id: trunk@32475 -
a bitcast that reads from and writes to the same register doesn't
work well
* changed pointerdef parameters of g_ptrtypecast_reg()/ref() to regular tdef
so that these routines can also be used with procvardefs (which are pointers,
but not pointerdefs), except for the fromdef of g_ptrtypecast_ref() as this
one has to call a_loadaddr_ref_reg() (which needs the pointeddef, and getting
that is not possible for non-pointerdefs)
git-svn-id: trunk@32417 -
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 -
thlcgobj.g_set_addr_nonbitpacked_field_ref() and adjusted it so that
it also works for objects/classes (if the incoming reference points
to the start of the class contents)
o factored out the related code from tllvmsubscriptnode
git-svn-id: trunk@32411 -
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 -
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 -
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 -
as an alias for the old one (rather than creating an interprocedural
jump, which is not possible in llvm IR and which is less efficient
anyway) (declaration for this method was already accidentally committed
in r30722)
git-svn-id: trunk@30777 -
because due to aliasing symbols a single symbol may be called using
different procdefs (e.g. FPC_ANSISTR_UNIQUE in the system unit is defined
as an alias for a function and called as a procedure). This means we have
to insert extra type conversions for llvm, which requires both the source
and destination type
git-svn-id: trunk@30776 -
