case a record contains an internal typed constant of its own type
(which happened becuase such a typed constant is also fieldvarsym, solved
by checking for sp_static) (mantis #27880)
* fixed several other similar cases in the compiler where we are only
interested in instance fields, but processed all fieldvarsyms
git-svn-id: trunk@30614 -
(abstract)recordsymtables, so that these settings don't depend on the
current user settings when internally creating record definitions
git-svn-id: branches/hlcgllvm@30343 -
instance methods that make use of the internal data builder
functionality so they automatically place all string data in the
same section if possible
git-svn-id: branches/hlcgllvm@30342 -
ttai_typedconstbuilder.finish_internal_data_builder() to generate data
will only be referenced by the typed const that we are currently
generating. Takes care of creating an appropriate label/section for
this data, avoiding needless global symbols and sections.
git-svn-id: branches/hlcgllvm@30339 -
should be dead-strippable; may imply the creation of a separate section
(on platforms that dead-strip data based on sections), but does not
require it
* replaced all existing tcalo_new_section uses with
tcalo_make_dead_strippable, as that is their meaning/purpose
git-svn-id: branches/hlcgllvm@30335 -
get_final_asmlist() to the constructor, in preparation of supporting the
creation of internal builders for local data that will ignore some of the
irrelevant flags (at creation time)
git-svn-id: branches/hlcgllvm@30334 -
ttai_typedconstbuilder.emit_string_offset() so it can also be used outside
the context of parsing a Pascal-level typed constant
git-svn-id: branches/hlcgllvm@30111 -
records is only known once we have completely parsed all of their data
(the alignment of a record depends on the alignment requirements of its
field with the largest alignment) -> only insert the padding bytes after
completely parsing them
git-svn-id: branches/hlcgllvm@28765 -
parsing from nllvmtcon to aasmcnst
o added automatic insertion of padding bytes when fields need to be aligned,
so that once ncgvmt (and hopefully ncgrtti) are converted to the typed
constant builder class, we can get rid of all the explicit alignment
directives (only supported for non-bitpacked records for now)
git-svn-id: branches/hlcgllvm@28763 -
procdef.getcopyas(procvardef,pc_address_only) as the def if we want to
specify that we're interested in the address of a procedure/procvar of
object
git-svn-id: branches/hlcgllvm@28476 -
get the offset relative from the returned label from
emit_(ansi|unicode)_string() to the start of the string data
o corrected return value for the offset on LLVM: it's always equal to the
header size, since we can't emit labels in the middle of structured data
there
git-svn-id: branches/hlcgllvm@28324 -
advance (e.g. ansistring constants, as they consist of a header
followed by an array of char equal to the string length, or RTTI data)
o use begin_anonymous_record() to start recording the field types (if
necessary for the current target), and end_anonymous_record() at the
end to generate the recorddef
git-svn-id: branches/hlcgllvm@28323 -
ttai_typedconstbuilder so that it can be overridden by other platforms
* override get_string_symofs() for LLVM and always return 0, as you can't
have labels in the middle of a declaration on that platform
git-svn-id: branches/hlcgllvm@28140 -
ttai_lowleveltypedconstbuilder
o set the offset to 0 in the llvm constbuilder before calling
the lowlevel one, because it incorporates this offset already
via getelementptr instructions
git-svn-id: branches/hlcgllvm@28136 -
same string constant to be merged together into a single tai_string
(required to efficiently represent string constants in llvm assembler
--i.e., without splitting them into bytes--, while keeping the
flexibility in the typed constant parser to mix individual elements
and strings)
git-svn-id: branches/hlcgllvm@28135 -
the assembler level
o initially for use during the typed constant parsing, but usable anywhere
we generate initialised data in the compiler
git-svn-id: branches/hlcgllvm@28117 -
