constants on llvm, as you can only compare with "null" in that case
* convert all arguments to integers in case of pointer subtractions,
as pointer subtractions are not supported by llvm
git-svn-id: trunk@30485 -
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 -
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 -
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 -
o results in simpler code, and more importantly is required for some code
that expects a LOC_REGISTER after calling certain system unit helpers
(e.g. in ncgutil.new_exception)
git-svn-id: branches/hlcgllvm@28375 -
o there are no cpu registers on the llvm target, but generic code may still
occasionally allocate them via the generic routines in case of e.g. a
hardcoded use of a function return register
git-svn-id: branches/hlcgllvm@28373 -
have to emit the label we originally allocated for the fallthrough path (otherwise
the branch is not inverted at all, and moreover the caller will also emit the
original target label somewhere so it will be doubly defined)
git-svn-id: branches/hlcgllvm@28367 -
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 -
o the generic implementation ignores the need for bitcasts from pointers to
ordinals and vice versa, and also hacks around with offsets
git-svn-id: branches/hlcgllvm@28206 -
o doesn't reuse the generic code generator methods, as the div-to-mul/shift
optimization can be performed by llvm if necessary
git-svn-id: branches/hlcgllvm@28205 -
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 -
o remove the accompanying tdef operands from tai operands, because such
tai operands should have a tdef already
o check that every queued tai is a tai_simpletypedconst (which have a
type)
o wrap queued bitcast/getelementptr tai instances with a
tai_simpletypedconst
git-svn-id: branches/hlcgllvm@28154 -
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 -
rather than first concatenating everything, because in case of
instructions that have other tai as operands we have to ensure that
all previous output is flushed before the tai-operand is evaluated
(and written/flushed)
git-svn-id: branches/hlcgllvm@28125 -
o now simple typed constants (integer, floating pointer, pchar)
and (non-variant) record typed constants containing such
elements work for llvm
git-svn-id: branches/hlcgllvm@28124 -
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 -
backend (required for inserting bitcasts/ptrtoint/... operations inside
typed constant declarations)
o taillvm constructors for creating bitcast-style and getlementptr
operations that accept a tai as their source/base operand
git-svn-id: branches/hlcgllvm@28112 -
typed constant data
o llvm declarations now get an extra "initdata" list that contains the
typed constant data associated with this declaration (if any)
git-svn-id: branches/hlcgllvm@28111 -
to free up space for more ait_* types in taitype (can't have
more than 32 because they have to fit in a small set)
o factored out writing of floating point numbers as an array of
byte in the external assemblers
git-svn-id: branches/hlcgllvm@28105 -
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 -
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 -
o no support yet for many ait_* types, although eventually most of them
shouldn't be generated at all for the llvm target
o no support yet for calling "opt" (which optimises llvm bitcode) before
calling llc (which translates llvm bitcode into native code) -- compile
with -s and manually call "opt" with -std-compile-opts, -O1, -O2 or -O3
if you want to experiment
o override the assembler writer with the llvm one when compiling an llvm-
targeting compiler
o override the assembler file extension with .ll when compiling an llvm-
targeting compiler
git-svn-id: branches/hlcgllvm@26054 -
overridden by the llvm target
* override a bunch of other ngenutil methods with empty stubs for things
that are not yet supported when targeting llvm
git-svn-id: branches/hlcgllvm@26051 -
bitpacked arrays:
o separate the element size from the index when constructing the memory
references, so we can easily use the llvm getelementptr instruction
o handle conversion of s80real values from their array declaration
as array elements to floating point values when loading them
git-svn-id: branches/hlcgllvm@26050 -
support for loading data from parent routines in nested routines has to
be implemented explicitly via records, like for the jvm target)
git-svn-id: branches/hlcgllvm@26049 -
fpu: treat them as extended when they are loaded into registers, and as
int64 when loading from/storing to memory
git-svn-id: branches/hlcgllvm@26048 -
registers itself, it requires them to be in SSA form. Therefore we
spill all registers that are written more than once to memory.
+ support in the generic register allocator for generating code that is
SSA-safe
+ spilling helpers for llvm
git-svn-id: branches/hlcgllvm@26044 -
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 -
the paraloc information, and then adds llvm-specific information to the
paralocs
o only partially implemented, in particular function result handling is
not yet there
git-svn-id: branches/hlcgllvm@26040 -
basic block must end with a terminator instruciton (such as a branch) ->
when emitting a label, check whether the previous instruction is a
terminator instruction and if not, add an unconditional branch to the
label we are adding.
o Implemented at the tcg instead of at the thlcgobj level because
a) these methods don't need any high level type information
b) implementing them in thlcgobj would require making thlcg.a_label()
virtual and ensuring that no-one ever calls cg.a_label() in any
generic code
git-svn-id: branches/hlcgllvm@26038 -
o opcodes + string representation
o llvm string representations of targets supported by fpc
o supported fpc optimisations
o list of supported LLVM versions (currently only targeting 3.3)
git-svn-id: branches/hlcgllvm@26035 -
temp we allocate, we set the base register to a newly allocated
R_TEMPREGISTER. This allows for uniquely identifying a temp even if its
offset is modified.
git-svn-id: branches/hlcgllvm@26033 -
