[fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

J. Gareth Moreton gareth at moreton-family.com
Sat Oct 3 18:43:36 CEST 2020

Sounds like a fun thing to research, that's for sure.  Thanks Jonas.

I'm under the impression that exception code tends to be separated 
anyway, so it can't easily be separated much further. Code that checks 
"IOResult" though could be possibly marked as cold code, so long as it 
isn't too large (e.g. you might get diminishing returns if the branch is 
simply "WriteLn('File not found'); Exit;").

Code that executes if, say, a LongInt variable equals "-1" might be cold 
code, especially as that's often an error flag and is otherwise just one 
value out of 2^32 possibilities (i.e. statistically unlikely to be 
True), although it's tricky to know if an assumption is correct or not 
given an arbitrary block of code, and what the penalty is if code that's 
marked as cold is actually hot.

Gareth aka. Kit

On 03/10/2020 14:18, Jonas Maebe via fpc-devel wrote:
> On 01/10/2020 18:37, J. Gareth Moreton via fpc-devel wrote:
>> On a similar topic, one person mentioned that GCC and other compilers
>> sometimes 'outline' conditional branches by effectively moving the
>> branch into a nested procedure in order to help with caching.by giving
>> the main procedure a smaller memory footprint.
> There are actually at least two things you can do related to splitting
> hot and cold code (code that gets executed a lot and code that gets
> execute very little). And there are also two possible approaches to
> determine what is hot and what is cold code:
> 1a) use static properties: you use language knowledge to change the
> layout of code. E.g., you can assume with high confidence that exception
> code and code for failed run time checks will be executed very seldom.
> 1b) use dynamic properties: you first profile the code using
> representative inputs, and use that information to determine hot and
> cold code (or adjust your static assumptions)
> Next, you can use this information in two ways:
> 2a) to improve code caching, "all" you need to do is separate the hot
> and cold code . This is generally done by placing all cold code together
> at the end of a procedure, so you don't need to perform any outlining here.
> 2b) to improve stack frame size (and data caching) and superfluous
> initialisation of (managed) variables that are only used in cold code,
> you can outline parts of the code (and the associated data).
> I think that 1a + 2a would be the easiest to implement. One way would be
> to use two asmlists per procedure instead of one ("hotcodelist" and
> "coldcodelist", can be kept in tprocdef.implprocdefinfo), and set
> current_asmdata.CurrAsmList with the former or the latter as appropriate
> (probably in pass_generate_code of e.g. tcgtryexceptnode, and adapt
> g_rangecheck so it accepts two asmlists instead of one: one where to add
> to the check, and one where to add the "failed" code, ...).
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

This email has been checked for viruses by Avast antivirus software.

More information about the fpc-devel mailing list