[fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential

[J. Gareth Moreton]

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