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

[J. Gareth Moreton]

Oh right!  In that case, I can upload the code now... well, after I 
finish testing everything!  (I'll keep my platform-specific code in a 
personal branch though in case it doesn't work).

I have seen once source of inefficiency in the compiled assembly 
language and that's something akin to this (the code is to assign the 
result of a condition to a Boolean variable - for example, "Result := 
Value is TEnum;")

   cmpl   $##, %reg
   jnbe   @Lbl
   xorb   %al, %al
   jmp    @Done
@lbl:
   movb   $1, %al
@Done:

(Presumably the xorb %al,%al line was originally movb $0,%al before the 
post-peephole stage converted it) It might be this way because there was 
something else in between that was optimised out, but this could be 
optimised to:

   CMP    $##, %reg
   SETNBE %al

Note that there is one shortcoming that I've discovered while writing a 
test, and that you can't yet use as/is in a generic function - that is, 
if you have something akin to this:

generic function<T1, T2>(Value: T1): Boolean;
begin
   Result := T1 is T2;
end;

It will fail, saying that a class type is expected where T2 is 
specified. I'll open a separate issue for this once the first patches 
are accepted and cleaned up.

Gareth aka. Kit

On 07/07/2019 20:07, Jonas Maebe wrote:
> On 07/07/2019 07:33, J. Gareth Moreton wrote:
>> Maybe I'm missing something painfully
>> obvious here. Can I request an example
>> where such an invalid value/undefined
>> behaviour crops up in bitpacked records so
>> I can see what's going on? Logic dictates
>> that the number of bits required to store
>> an enum in that arrangement is equal to
>> the index of the highest element,
> That is correct, but the discussion revolves about storing elements that
> are larger than that the highest or smaller than the lowest element. In
> that case, bits gets lost when storing them in bitpacked versions.
>
>
> On 07/07/2019 19:36, J. Gareth Moreton wrote:
>> Additionally, I'm putting in an implementation specific to x86 because I
>> can take advantage of its ALU design to do the range check in as few as
>> 2 instructions (a comparison and either a conditional jump or a SETcc
>> instruction).  If the range exceeds the CPU size though, then it falls
>> back to the node-level, platform-agnostic method.
> That is not necessary. The compiler can do that trick itself (in a
> CPU-independent way). Before yesterday, it could only do it with
> unsigned ranges, but since yesterday it can also do it for signed ranges.
>
> It can't yet inline the fpc_is/as_enum because it calls an
> implementation-only procedure of the system unit, but I'm working on
> solving that as well.
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus