[m-rev.] for post-commit review: getting OISU information to the feedback tool

[Zoltan Somogyi]

On 24-Oct-2012, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> On Wed, Oct 24, 2012 at 02:59:26PM +1100, Zoltan Somogyi wrote:
> > Note that this diff is BREAKS binary compatibility for debug and deep
> > profiling grades.
> > 
> > For review by anyone.
> > 
> 
> I'm happy to review this.  But before I begin in earnest I would like to confirm
> my understanding of what you want to implement in the future.
> 
> As it stands this and your previous patches add a pragma that the programmer
> can use to indicate that making the updates to a value of a certain type out of
> order is okay, and implicitly desirable for performance.  This patch makes
> this information available to the deep profiler and feedback tool.  My
> questions are.  Do you want the feedback too to check the global uniqueness of
> the value of this type?  Also, should the feedback tool attempt to parallelise
> the program as if uses of this variable cannot form a dependency?  Thereby
> requiring the compiler to generate code that makes a global store for a
> variable of this type and provide synchronisation?
> 
> These questions may be harder to answer.  How can the compiler be sure that the
> variable of this type is globally unique?  In particular, the compiler cannot
> completely trust the feedback, but only the feedback tool can analyse the whole
> program?  This may also get complicated when linking to 3rd party libraries, a
> library may create a second instance of such a variable.  It will be possible
> to use runtime checks, but I would rather detect any problems at compile time.

These issues are discussed in the OISU design document, which I have now
added to the compiler/notes directory.

> > deep_profiler/query.m:
> > 	Recognize a query asking for the new report type.
> 
> Can I execute the query from the UI?

Yes. There is now a link for it on the module summary page.

> You can add 'developer only' options using the appropriate constructors in the
> display structure.  I suggest on each module page adding a developer only
> link to this report.

Why would you want to make it developer only?

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------