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 -
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 -
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 -
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 -
for function results and parameters (they're not in an aggregate, and this
caused 80 bits extended floating point types to be translated into arrays
of 10 bytes, which have different ABI meanings)
git-svn-id: trunk@30714 -
handle recursive record references (rec= record prec: ^rec)
o llvm unfortunately does not support recursive references to array types
or function pointers, so those will currently still result in endless
recursion when the compiler tries to write them out. Solving those
will require a lot of typecasting in the generated code
git-svn-id: trunk@30675 -
so that if a_loadaddr_ref_reg() is used to load the address of a procdef
into a register, the getpointerdef(procdef) won't (wrongly) result in two
*'s
o the previous behaviour was necessary for the tck_simple_procvar2proc
special case that was removed in the previous commit
git-svn-id: branches/hlcgllvm@28477 -
llvm
* instead, add LLVM-specific name mangling based on the asmsymbol's bind
and typ whenever we write out its name
git-svn-id: branches/hlcgllvm@28166 -
a procvardef
* handle procdefs like procvardefs when getting their string representation
in arbitrary expressions
git-svn-id: branches/hlcgllvm@28123 -
convert one def to another, including information regarding whether
it should be done via an intermediate integer typecast
* use this routine in hlcgllvm
git-svn-id: branches/hlcgllvm@28116 -
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 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 -
Other than arrays and complex procvardefs, all aggregates are currently
handled as opaque arrays of bytes
o special case: s80real (x87 extended type) is encoded as "array[0..9] of
byte" inside arrays, because when using the llvm type describing
"extended" llvm will handle it in an ABI-compliant way (allocating e.g.
16 bytes for it on Darwin and x86-64 platforms). Loading/storing them
always happens using instructions that only read/write 10 bytes, so
we only have to take care to convert them to the actual extended type
when indexing arrays/subscripting records (when records are no longer
handled in an opaque way)
git-svn-id: branches/hlcgllvm@26041 -
