it can be directly indexed rather than that we need to separately
select the byte or data (just like at the Pascal level, and how it
is/will be handled in the code generator)
git-svn-id: branches/hlcgllvm@27015 -
o make use of the fact that callparanodes always first load everything
in temporary parameters (allocated via paramanager.createtempparaloc)
-> we pass those temporary paralocs to the llvm call nodes and ignore
the "real" locations with physical registers
o all function results are forced to memory before handing them back
to the generic code generator to avoid having to deal with special
result locations and llvm<->pascal type differences (llvm removes
the extra temp stores/loads while optimising)
o ideally, the llvm code generator should share the common code with
the generic code generator for a_load_ref_cgpara() at some point in
the future
git-svn-id: branches/hlcgllvm@27013 -
generate declarations when external symbols are referred in a taillvm
instruction
* added "declared" field to tasmsymbol for llvm to make avoid declaring a
symbol multiple times (harmless, but unnecessary)
* all kinds of declarations/definitions are now handled using the new
taillvmdecl, the old separate types have been removed
git-svn-id: branches/hlcgllvm@27010 -
o handle parameters and function results divided over multiple paralocs,
including generating fake recorddefs that represent
o fixed zero/sign extension handling
o properly handle difference between procdefs as printed for the
implementation, an alias declaration or a procvar definition
git-svn-id: branches/hlcgllvm@27009 -
for llvm, and empty for other targets:
o the '@' is required to mark a global/static symbol identifier in llvm
o the double quotes are required in case special characters are involved
o the \01 means that the name should not be mangled by llvm (e.g., by
default it still adds the C-prefix to all symbol names, and replaces
some special characters with alternatives)
* apply this prefix/suffix in all name mangling routines
git-svn-id: branches/hlcgllvm@26995 -
gcc and clang always allocate them in multiple of 4 bytes too (except in
case of _Bool, which is 1 byte -> do the same for PasBool) and this is
one possible interpretation of the ABI. This also frees us from having to
perform special adjustments afterwards to ensure that smaller values are
sign/zero-extended to 32 bits
git-svn-id: branches/hlcgllvm@26993 -
required for the LLVM support (LLVM parameter support is not yet
included)
* always return the function return loc from a_call*, again as required
for the LLVM support
git-svn-id: branches/hlcgllvm@26992 -
that contains their mapping to LLVM (mainly getting rid of variant parts
and adding explicit padding when not using {$packrecords c})
git-svn-id: branches/hlcgllvm@26988 -
destination types are different: the pointer types of the load/store must
be converted in that case, rather than the loaded/to be stored value
(you can't bitcast aggregates in LLVM)
git-svn-id: branches/hlcgllvm@26987 -
will be used to load them afterwards instead of always per byte so we
can use that loadsize as the array element type in llvm declarations
(-> less casting required)
git-svn-id: branches/hlcgllvm@26977 -
