[PATCH] tracedump: add --help and --function-histogram

[José Fonseca]

On Sun, Sep 11, 2011 at 1:44 AM, Zack Rusin <zack at kde.org> wrote:
> On Saturday, September 10, 2011 07:56:51 PM José Fonseca wrote:
>> I don't understand the meaning of a "pass" here. Could you give
>> concrete examples?
>
> Basically the same as with llvm. More specifically: algorithms that operate on
> the internal model for a specific purpose.
>
>> AFAICS, if a GL misuse analysis is sought, then the calls have to be
>> replayed/analysed in order, from start to
>> finish, because GL state can only be queried within the context of all
>> previous calls replayed in sequence. That is, everything must be done
>> in a single pass,  a single read of the trace file.
>
> That would be example of a specific pass. Other examples would be histogram
> generation, a pass that uses something like lunarglass or another framework to
> see if it's possible to optimize the generated shaders, a pass that suggests
> replacement of older gl api calls with newer stuff, i.e. anti-deprecation pass,
> a pass that suggest optimizations by way of replacement of a set of calls with
> some new extension, etc. Stuff like that. Some of them requiring current api
> state, some of them not.

This helped me to understand where you're aiming at.

But does the concept of a LLVM pass really fit well here?

First, traces can be huge and in general won't fit in memory, so
passing over the full trace over and over again is inefficient due to
the need to re-read & re-decompress from disk. An architecture where
all these things you seek are done simultaneously on a single pass is
better.

Second, there is not much value in rewriting an improved trace (other
than maybe a validating benchmark). The final goal is to provide a
detailed report to the user so that the user can go then modify his
application accordingly [1].

In summary, IMO it would be better to abandon the "multiple
configurable passes" mindset for the one of "a single pass that
generates an exhaustive report of how to improve the application".
Anyway, this is merely a suggestion, as having the things you envision
above implemented would be pretty cool, regardless of the chosen
architecture.

Jose

[1] BTW, we should start recording the call-stack so that we can
provide links straight to the application source code in question.