It's probably a good idea, yes. Normally the optimisations I implement
are due to me spotting something in the RTL or compiler disassembly
while optimising something else, so the tests per se are in those
units. Dedicated tests, like my recently added POPCNT tests, are a good
idea even if the set-up is quite uncommon (e.g. it's rare that one would
check, say, PopCnt(X) = 0 (or <> 0) because checking X directly gives
you the exact same result - in that particular case, I added it because
it was as simple as adding a couple of labels to a case block.
How should we start with making these tests?
Gareth aka. Kit
On 09/01/2022 11:14, Florian Klämpfl via fpc-devel wrote:
Am 09.01.2022 um 08:09 schrieb J. Gareth Moreton via fpc-devel
<fpc-devel@lists.freepascal.org>:
Some people requested a Patreon post as to my plans for 2022 with FPC, so I was
happy to oblige. Plans may change a bit though depending on what happens in
life and also what Florian's own vision is with the compiler, but this is the
gist of it:
https://www.patreon.com/posts/60922821
One thing we should think about: the current optimizations being added get more
and more rare so they are often not tested anymore by the existing regression
tests. So maybe we should think about a dedicated facility for assembler
optimization testing.
_______________________________________________
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
