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@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
