This is a very common construct in normal code and also heavily used in
softfpu code.
The ARM-cg will now just test for the MSB of reghi to be set, instead of
a full comparison against constant 0.
git-svn-id: trunk@28315 -
* int64_to_float64 and qword_to_float64: call 'function' overload of PackFloat64. Whenever arguments are constant it can be evaluated entirely at compile time (the procedure PackFloat64 does not have this property even if marked as inline because it is too complex, i.e. consists of more than single statement).
git-svn-id: trunk@28307 -
+ a_load_const_ref: use CLR and MOV3Q if possible.
* a_cmp_reg_reg_label: force size to 32 bits for ISA_A and ISA_A+ targets.
+ support for stack frames larger than 32767 bytes.
git-svn-id: trunk@28298 -
+ support spilling at offsets >32767, tested only to generate assemble-able code, support of large stack frames needs more changes elsewhere.
git-svn-id: trunk@28295 -
- for ftBlob parameters binding use temporary LOBs instead of long varraw to bypass 64KB limit of current implementation
- initial support for NCLOB data type (if client uses for NCHAR "variable width" charset (like UTF-8) then there is character length <> byte length which is currently not handled correctly)
git-svn-id: trunk@28286 -
There was an interference between the load scheduler and then
Str/LdrAdd/Sub2Str/Ldr peephole optimizer.
ldrb r0, [r2]
ldrb r1, [r2, #1]
orr r3, r0, r1
add r2, r2, #2
got changed pre-regalloc to:
ldrb r1, [r2, #1]
ldrb r0, [r2]
orr r3, r0, r1
add r2, r2, #2
and the peephole optimizer collapsed the add into the second ldrd:
ldrb r1, [r2, #1]
ldrb r0, [r2], #2
orr r3, r0, r1
Then the post-peephole optimizer changed that into:
ldrb r0, [r2], #2
ldrb r1, [r2, #1]
orr r3, r0, r1
so r1 got loaded from a modified base-register.
This patch prevents the scheduler from moving an ldr-instruction if it
uses Pre/Post-indexing and the instruction before it uses the
base-register.
git-svn-id: trunk@28284 -
FPC_{DIV,MOD}_QWORD now check if both inputs have their upper 32bit set
to zero and in that case use 32-bit division instead, which many
plattforms can either do in hardware or have optimized assembly code
for.
git-svn-id: trunk@28279 -
will only be used for indexing huge pointers (i.e. only huge arrays with the
ado_IsConvertedPointer array option will be supported). In the distant future,
regular huge arrays may be supported as well (but that would require
substantially more work, including adding hugeness support to other structures
such as records, objects and classes, so I'm not planning on doing it anytime
soon).
git-svn-id: trunk@28270 -
symdef.pas:
+ tabstractrecorddef: implement buildderefimpl and derefimpl which works on the symtable (especially derefimpl is important here)
- trecorddef & tobjectdef: remove buildderefimpl; it's already handled by the tabstractrecorddef one now
- tobjectdef: remove the part of derefimpl that's already handled by tabstractrecorddef
git-svn-id: trunk@28267 -
Comparisons are already not promoted if sides are equally signed, but this wasn't true for "unsigned vs constant" case, because constants are preferably parsed as signed.
The change considerably improves generated code for i386 and even more considerably for m68k. Tested on i386-win32.
git-svn-id: trunk@28266 -
* Better handling of LOC_CREGISTER locations.
+ Support direct compares of constants with references.
+ Optimize away comparison of low dword when its result is constant (cases of "less" and "greater or equal" comparing against a constant with zero low dword).
git-svn-id: trunk@28263 -
