That matches its meaning better, as it should not result in type conversions.
E.g. some kinds of metadata parameters expect a "type register" parameter such
as "metadata i32* %reg.3"
treating them as opaque defs. This is required to ensure that the temporary
recorddef for all x86-64 function results are the same on the caller and
callee side, as we allocate new arrays when generating them
git-svn-id: trunk@47584 -
o they are implemented as a new metadata register class, whereby the
subregister indicates the metadata type (currently always a string)
and the superregister is an index in the metadata array (which
contains the strings). LLVM metadata can only be passed as parameters
to intrinsics in bitcode, so moves of metadata into other registers
triggers internal errors and when moving them into parameters, we
replace the parameter's register with the metadata register (and look
up the corresponding string when writing out the bitcode)
git-svn-id: trunk@43816 -
they're an exact multiple of the ialignment size on LLVM. This prevents
both overalignment (e.g. remainder of 8 individual bytes on ARM
would be aligned to 8 bytes instead of 4 if typed as int64) and
underalignment (e.g. 32 bytes remainder of a record that needs to be
aligned to 8 bytes would be aligned to 1 or 4 bytes if types as
array of resp. bytes or longints)
git-svn-id: trunk@41444 -
size doesn't match the number of remaining bytes
o prevents a second "single" field of a record getting interpreted as a
"cardinal"
git-svn-id: trunk@40569 -
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 -
as list of defs to be stored in the record, so we don't need to create and
free a class instance every time we call this routine
git-svn-id: trunk@35155 -
the buffer in the type, and support typecasting the typed file to a
different size (needed to be able to pass it to the compiler helpers that
expected a "TypedFile", whose buffer is 0 bytes and which hence will
always have a smaller size than the original type) (fixes test/tisoext1)
git-svn-id: trunk@35017 -
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 -
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 -
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 -
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 -
