On an extra note, the assembly language produced is not yet optimal, so
it may end up that an x86-specific implementation will be beneficial.
TIsNode contains a virtual method named "DoVariableEnumCheck" that would
allow such an extension, coupled with returning "nil" that would defer
code generation to "pass_generate_code" (allowing this, but not
overriding "pass_generate_code", will trigger an internal error, because
the 'is' node normally never allows it to be called). Nevertheless,
even if that is a no-go, it's making me a little excited to see if I can
find new peephole optimisations to implement. But until my old x86_64
overhaul is accepted, rejected or reworked (at least to make it
successfully merge), I can't really make any new additions yet.
Gareth aka. Kit
P.S. One optimisation I would like to suggest across all platforms, if
at all possible, is to defer register allocations until after the first
peephole optimisation stage, because I see sequences like this on i386
when working with Int64's (this particular sequence sign-extends from
LongInt to Int64):
mov %reg1,%reg2
sar $31,%reg2
This fills %reg2 with all 0s or all 1s depending on if the sign bit is
set in %reg1. However, if the registers are still virtual, it may be
possible to evaluate nearby code and request a preference for %eax for
%reg1 and %edx for %reg2 (certain operations like "mul", "div" or
function parameters require the use of %eax and %edx specifically) -
that way, the sequence can be collapsed into a single call (and a single
byte in size) to "cdq".
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
