list, so that the assembler directives generated for Darwin are emitted
correctly for LLVM
o extracted the library init code generation from hlcgobj to pmodules so
we don't add things to another list than what's passed to
gen_proc_symbol_end(), and so it's done where we generate the init
routine for libraries (rather then checking for every routine whether
it's the init routine for a library)
o removed the llvm-specific gen_proc_symbol_end() because the regular one
now does the same
git-svn-id: trunk@34134 -
moved the code to create the procedure start/end etc. that was at the
call sites of g_external_wrapper() into the new g_external_wrapper()
-> got rid of the x86-specific code in expunix, and fixed expunix for
llvm (e.g. tests/test/tlib1{a,b})
git-svn-id: trunk@34131 -
methods. Implementing a fully functional g_external_wrapper() for llvm is
quite hard, and the regular wrapper method that calls FPC_ABSTRACTERROR can
in principle be optimized to a plain jump by tail call optimisation on other
targets (to the extent that this matters, because most of them will be
smartlinked away, and the ones that are executed will trigger an exception)
o this means that the synthetic method generation needs to be run for all
objectdefs on all platforms now, rather than only for Java classes
git-svn-id: trunk@34127 -
than of their loadsize, because otherwise if they are e.g. part of a record
they would occupy more space than allowed
o adapted llvm code to deal with the fact that bitpacked arrays are now
always arrays of bytes rather than arrays of integers with the same size
as their loadsize -- this also fixes several type inconsistencies
detected by llvm
git-svn-id: trunk@34125 -
of the same size -> ensure that this is the case for the shifts in
a_bit_test/set_reg_reg_reg() (fixes tests/tbs/tb0219.pp for llvm)
git-svn-id: trunk@34123 -
using their actual type (array/record) rather than using the
simplified type (void), so we can also return an actual value and
assign it to something (void means that nothing is returned and
cannot be assigned to anything) (completes fixing
tests/test/tnoext4.pp for llvm)
git-svn-id: trunk@34120 -
(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 -
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 -
records: as an array of 10 bytes. We handle indexing dynamic arrays
the same as indexing other arrays, and hence that code expects extended
to be encoded the same way.
git-svn-id: trunk@34116 -
always be different from the old location, since we just allocated
the registers for the new one above. Should the old registers ever
be needed again for tai_varloc: rr.old/rr.oldhi contains it
git-svn-id: trunk@34086 -
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 -
as bytes in the LLVM type, so typecast them to the correct type (which is
the size that will be used by hlcg.a_load*subsetref*)
git-svn-id: trunk@32565 -
a pointer to a vmt, but a pointer to a pointer to vmt (mantis #29086)
o also adjusted the llvm type for interfaces accordingly
git-svn-id: trunk@32530 -
if the it's an addn/subn. For comparisons, the resultdef is boolean, and
left and right will already have the same type (with addn/subn, one could
be a pointer and the other an integer)
git-svn-id: trunk@32523 -
dbg_state is not sufficient to determine whether or not a def has
already been processed or not -> use stab_number (and reset it)
o also record all defs we don't emit "type" instruction for, but which
we still process to find other defs, so we reset those too
git-svn-id: trunk@32520 -
because the names we assign to parameter locations are no longer valid after
a module has been compiled (they are tasmsymbols), and they're not necessary
for declarations either; this also avoids generating calleeside parameter
information for imported routines just to write the external declaration
(the callerside information will already be available from when the routines
were called)
git-svn-id: trunk@32518 -
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 -
they exist even if we try to read them before writing to them (e.g.
because they represent the uninitialised function result of an
inlined function)
git-svn-id: trunk@32465 -
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 -
"don't free even if not registered"; use for defs that may not be written
to a ppu file, but that must nevertheless survive the compilation of the
current module
* mark all defs created for para locations as "don't free even if not
registered", because we don't discard and recalculate all para locations
after a module has been compiled (since that's not needed)
o solves issues if the paralocations for a routine in the interface of
unit A are calculated while the implementation of unit B gets
compiled, and a new reusable type is allocated at that point which
is not used anywhere else (after r32160)
git-svn-id: trunk@32235 -
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 -
are the first parameter (as required by llvm)
o ensure that for AArch64, "struct return" the parameter always is the first
parameter, as it needs to be returned in a special register there
git-svn-id: trunk@31676 -
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 -
