* For single-precision variant, truncate to 64 bits instead of 32, since this how trunc()/round() are defined.
* Do not access float64 as int64, doing so would break on ARM hardfloat after r26010.
git-svn-id: trunk@26065 -
* ti8086.moddivnode.pass_generate_code: use cg.a_op_const_reg, instead of
emit_const_reg, in order to support generating plain 8086/8088 code
(shr/shl/sar reg,const is 186+ if const is >= 2).
git-svn-id: trunk@26063 -
llvm-targeting compiler, but use llvmnode instead
o after this commit it possible to build an llvm/x86-64 compiler with
very limited functionality (you can only compile dummy system units
containing procedures --not functions!-- with simple arithmetic
and array expressions; parameters are partially supported, making
calls is not). Use a make command line similar to the following:
make OPT="-Fullvm -Fillvm -dllvm" PPC_TARGET=x86_64 clean all
The resuling compiler can generate (some) valid code for at least
Mac OS X/x86-64 and should also be able to target Linux/x86-64.
Win64 support may work by simply adding it to the list of supported
targets in as_llvm_info in llvm/agllvm.pas.
git-svn-id: branches/hlcgllvm@26058 -
default -O1/2/3 optimization levels and supported optimization switches
(e.g. -Ooregvar is not supported for the llvm target, nor needed)
git-svn-id: branches/hlcgllvm@26055 -
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 -
do_spill_replace routines, will be necessary by llvm register
allocator to determine the tdef corresponding to that register
* replaced uses of taicpu with tai_cpu_abstract_sym in the register
allocator so that it can work both with taicpu and taillvm instructions
git-svn-id: branches/hlcgllvm@26043 -
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 -
