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 -
