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

[J. Gareth Moreton]

Most of it is node-level.  Ondrej's method was to use an inlined 
compilerproc to do the range check, but the parameters are of type 
SizeInt, which causes problems if the range to check against is of size 
Int64 or, worse, QWord.  It may be that after some refactoring, the 
nodes for such an inlined procedure can be inserted directly rather than 
just inserting a procedure call.

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.

It's probably better to simply show the code for scrutiny once I get it 
ready, rather than try to explain myself.  Nevertheless, there may be 
some peephole optimisations that are to be added, but I haven't worked 
on that in a while due to my overhaul that needs updating so it at least 
merges with the latest trunk and doesn't undo a load of more recent changes.

Gareth aka. Kit

On 07/07/2019 09:24, Florian Klämpfl wrote:
> Am 07.07.2019 um 07:33 schrieb J. Gareth Moreton:
>> 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, although
>> that's without looking at the source code
>> and doesn't account for elements that have
>> assigned negative values.
>>
>> In the meantime, I'm working on making
>> "as" and "is" work with ordinal types as
>> well as enumerations, although currently
>> some headaches occur if the right-hand
>> side is larger than the CPU word size
>> (e.g. Int64 on i386). I'll upload the
>> patch to the issue once it's working
>> properly.
> I strongly recommend to add these changes at node level, then you do not have to fiddle with the alu sizes of different
> CPUs.
> _______________________________________________
> 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