[profile-stdlib][patch] Stdlib advisory tool implemetation

[Silvius Rus]

On Thu, Aug 28, 2008 at 2:43 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>
> Hi,
>
> and first congratulations for the excellent progress in this project!
>
> I have a few rather basic comments:
> 1- Certainly new testcases don't go in 31_*, because those numbers correspond to chapters in the Standard, and I don't think this is an ISO Standard yet ;) Maybe subdirectory of the existing onew are ok, as we are doing for debug-mode. Or, if you want, a separate subdir is ok, but with a different name.
> 2- Are you really, really, sure you have to change the compiler driver? First, we are very close to the end of Stage 1, and we have only a few days to convince the compiler maintainers that this is an important change for 4.4.0, in case should be submitted separately and clearly "advertised". Anyway, for debug-mode and parallel-mode we don't do that, and, at the very least for consistency, I think we should reconsider carefully the option of simply defining macros.
> 3- Similarly, are you really, really, really, sure you need a separate library? For debug-mode, which isn't really trivial, we managed to avoid that.
> 4- Afterwards, there are smaller issues, like I'm seeing many non-"uglified" symbols in headers included by the user-code, this is a no-no, *everything* (besides the names of functions, classes and constants specified in the Standard, of course) must begin by __ or _ + Capital (macros included, really there are no exceptions).
> 5- In general, we never include C headers, always the <c*> versions and we qualify with std:: the calls.
> 6- More important, **make sure** not using anything not in C89 without proper configure-time tests checking for the availability of the facility on the given target (then, conditionally, it's Ok including, e.g., <execinfo.h>)
>
> Huumm... if the above issues are satisfactorily resolved, I think we are actually not so far from committing something!
>
> Paolo.
>


Hello Paolo,

Thank you for your comments.  This looks like a good time to try to
merge into trunk.  The project has been asleep for a while, but I
believe there's good value in it.  Some things have changed since last
time I brought it up, so I have a few big picture questions before I
jump in.

The work flow goes like this currently:
1. Run a model training binary (once per machine type), to produce a
machine specific library performance database.
2. Run compiler with -fprofile-stdlib to produce instrumented code.
3. Run instrumented code to produce trace.  The performance database
must be available during the run.
4. Run a binary to interpret the trace and produce a human readable
diagnostic.  The performance database must be available at this time
as well.

It is not very clear to me how to integrate this cleanly.  Can you
answer any of the following questions?

1. Where would the training binary go?  This is a standalone
collection of small STL programs that exercise various library
functions and produce the library performance database.  It also comes
with some utilities.  The only communication between this and the rest
of profile-stdlib is through the library performance database, which
is a set of data files that can be packed into an archive.

2. Where would the code that reads the trace and produces the
diagnostic live?  I'd like this to be part of stdlib-profile, so that
it can be called as soon as the instrumented binary completes
execution.  But it should also be available as part of a utility such
as gprof, so that, for instance, multiple traces can be merged.  What
do you think?


Thank you,
Silvius