#10 Allow custom aggregate functions for events / costs

[Hagen Graf]

I was trying to use KCachegrind's great visualization capabilities for a kind of data-flow analysis, when I unfortunately hit a limit…
However, it might be easy to overcome, and it might be a generally useful feature for the program.

What I'm trying to visualize

I have an algorithm which makes use of floating-point variables. I'm trying to figure out if some parts of the algorithm use only a limited range of values, in order to optimize those parts by using fixed-point variables or smaller floating-point formats.
I know that this kind of optimization doesn't make sense in desktop computers, but it's planned to be used for porting algorithms to Microcontrollers or even FPGAs or ASICs.

Fictive KCachegrind Input File

I created the following input file for KCachegrind manually (i.e. the corresponding program doesn't exist).
It can be opened and visualized, but the "events" minExp, maxExp and range are accumulated, which doesn't make sense.

positions: instr

event: flops : Floating-Point Operations
event: minExp : Minimum Exponent
event: maxExp : Maximum Exponent
event: range = maxExp - minExp : Dynamic Range
events: flops minExp maxExp

fl=file1.c
fn=main
16 20 10 80
cfn=func1
calls=1 50
17 400 15 70
cfl=file2.c
cfn=func2
calls=3 20
18 400 10 80
19 10 10 90

fn=func1
51 100 15 70
cfl=file2.c
cfn=func2
calls=2 20
52 300 15 70

fl=file2.c
fn=func2
20 700 10 80

My proposed solution

As mentioned in the title, a flexible solution would be the use of custom Aggregate Functions borrowed from databases.
This function would be used to calculate the Inclusive- and Self-Cost, if multiple cost lines are given.
In my case, the aggregate function for flops would be sum(), for minExp min(), for maxExp max(), and for range also max().
Maybe a possible syntax could be

event: flops : Floating-Point Operations
event: minExp(min) : Minimum Exponent
event: maxExp(max) : Maximum Exponent
event: range(max) = maxExp - minExp : Dynamic Range

Of course, sum() should be the default aggregate function.

For aggregate functions other than sum(), the relative cost view of KCachegrind doesn't make a lot of sense, however, it wouldn't do harm… (values >100% would be possible)