o use this to handle non-power-of-two-sized parameters for llvm
o no general support in the parser/code generator, so don't expose
git-svn-id: trunk@40398 -
so that they can still be freed after the reference has been changed
(e.g. in case of array indexing or record field accesses) (mantis #33628)
git-svn-id: trunk@38814 -
indirectly depends on llvmpara and hence is initialised after instead
of before it (since llvmpara should override cpupara in its init code)
git-svn-id: trunk@36264 -
o separate information for reading and writing, because e.g. in a
try-block, only the writes to local variables and parameters are
volatile (they have to be committed immediately in case the next
instruction causes an exception)
o for now, only references to absolute memory addresses are marked
as volatile
o the volatily information is (should be) properly maintained throughout
all code generators for all archictures with this patch
o no optimizers or other compiler infrastructure uses the volatility
information yet
o this functionality is not (yet) exposed at the language level, it
is only for internal code generator use right now
git-svn-id: trunk@34996 -
it was AT_NONE, which is invalid and should never be used
* explicitly pass the correct value for all calls to those methods elsewhere
in the compiler
git-svn-id: trunk@34250 -
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 -
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 -
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 -
(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 -
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 -
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 -
assembler function, as the inline assembly code itself will be
responsible for returning the function result (we will have to add
the "return" instruction to it) while llvm requires a terminator
at the end of the function and it must return something
git-svn-id: trunk@30671 -
o results in simpler code, and more importantly is required for some code
that expects a LOC_REGISTER after calling certain system unit helpers
(e.g. in ncgutil.new_exception)
git-svn-id: branches/hlcgllvm@28375 -
o there are no cpu registers on the llvm target, but generic code may still
occasionally allocate them via the generic routines in case of e.g. a
hardcoded use of a function return register
git-svn-id: branches/hlcgllvm@28373 -
have to emit the label we originally allocated for the fallthrough path (otherwise
the branch is not inverted at all, and moreover the caller will also emit the
original target label somewhere so it will be doubly defined)
git-svn-id: branches/hlcgllvm@28367 -
