[fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton gareth at moreton-family.com
Mon Jul 8 02:52:26 CEST 2019


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



More information about the fpc-devel mailing list