It's funny - for some reason I was expecting a lot of opposition!
I knew about FillChar being written in assembly langauge and know from
experience that FPC will never support the inlining of pure assembler
routines (as Florian said, it will just open a huge can of worms). My
thought was how to get around the intrinsic and procedure having the
same name, since I can't just rename the procedure to, say,
_fpc_fillchar because that will break backward compatibility in some
situations.
While I'm a little wary about hard-coded constructs like "if proc =
System.FillChar then ReplaceWithIntrinsic" since it seems inflexible,
this is probably one of those times that it's justified, and as people
have said, it's been done with Insert and Delete aready.
Even if inlining or pure functions were a thing (that's still on my
agenda), it wouldn't work with FillChar due to the assembly language.
Also, things like checking a variable's memory alignment wouldn't be
able to be optimised out without additional information from the
compiler that's generally only available at the node level (in the
compiler, a type's base alignment is a property you can very quickly
retrieve, without having to go through the mess of checking to see if
the base register is RSP and the offset some multiple of 8 or something).
Sounds like something to start experimenting with!
Gareth aka. Kit
P.S. I also worked out that the reason why PXOR; MOVDQU is slower than
just setting the fields manually is also because there's a pipeline
stall between PXOR and MOVDQU, whereas just writing 0 to a load of
memory locations using MOV doesn't have this problem.
--
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
