[fpc-devel] x86_64 Optimizer Overhaul

J. Gareth Moreton gareth at moreton-family.com
Sat Dec 15 20:17:24 CET 2018


 Apologies for my webmail client problems.  There's little I can do about
that.
 This was the object pooling that I did -
https://bugs.freepascal.org/view.php?id=34679 - though there's some cycle
counting involved (e.g. in OptPass1MOV, only the integer registers are
updated instead of all 8 types), this little bit of refactoring also fixed
a couple of memory leaks as a side-effect, since two of the peephole
optimisation routines created an array of TUsedRegs objects, but failed to
free them afterwards.  There are also quite a few locations where
ReleaseUsedRegs is called multiple times in the same routine, mostly in an
attempt to avoid using a "try...finally" block.  Such configurations are
just asking for a bug to be introduced where it's forgotten in one of the
branches.

 Gareth aka. Kit

 On Sat 15/12/18 19:37 , Martok listbox at martoks-place.de sent:
 Sorry for hijacking the thread. Your mail client issue makes the
conversation 
 really hard to follow, so I have literally no idea what the current
subtopic of 
 a reply chain is, and there's little point in properly detaching a thread.


 Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton: 
 > I dare ask, does that mean we should avoid workarounds in the compiler
(and 
 > our own programs) that aim to avoid constant construction and
destruction of 
 > objects, and instead try to improve the memory manager? 

 I was thinking more along the lines of avoiding cycle-counting special
paths at 
 the cost of reliability, when there are much larger issues that would
benefit 
 every program. 

 I would not be surprised if some of the large difference Simon listed when

 calling out the bounty come from this side, instead of raw instruction
throughput. 

 > Thus, I would imagine that Delphi's *default* internal memory management

 > system is more along the lines of what is done in FPC's cmem unit, which
is 
 > well known to be objectively faster than FPC's default memory manager 
 I'm fairly certain the runtime is written in Pascal, except for parts of
the 
 startup code. The memory manager at some point (I think D2006?) adopted
FastMM: 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
------
[1]
http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager%26gt
[2] mailto:fpc-devel at lists.freepascal.org
[3] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181215/503ab311/attachment.html>


More information about the fpc-devel mailing list