[m-rev.] ssdb v1.0 fixed

[Ian MacLarty]

On Wed, Dec 05, 2007 at 05:38:19PM +1100, Julien Fischer wrote:
>
> On Wed, 5 Dec 2007, Ian MacLarty wrote:
>
>> On Wed, Dec 05, 2007 at 02:55:19PM +1100, Julien Fischer wrote:
>>>
>>>
>>>
>>> On Wed, 5 Dec 2007, Peter Wang wrote:
>>>
>>>> On 2007-12-05, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>>>>>        I'm not sure where the ssdb transform should go. I assume as
>>>>>> early
>>>>>> as
>>>>>> 	possible.
>>>>>
>>>>>  I think the opposite is probably true.
>>
>> Can you explain your rationale?
>
> For the same reasons that the deep profiling and term-size
> profiling transformations are done late in the piece; the transformation
> introduces changes the code in various weird ways that are likely
> to confuse various other transformations.
>
>> I think earlier is better, because
>> generally user's don't want to debug code that's been transformed into
>> something unrecognisable (note that the target users of the debugger
>> should be Mercury users, not the compiler developers).
>
> So turn the transformations that affect the code off then.
>
>>>>
>>>> One problem with doing that is that putting breakpoints on the original
>>>> procedures won't work reliably because earlier transformations may have
>>>> e.g. specialised that procedure and changed the call sites.  Which
>>>> practically means disabling all transformations that might affect the
>>>> user's view of the program if ssdb is enabled.
>>>
>>> Which is what mdb does.  I think trying to preserve the user's
>>> view of the program in the presence of program transformations is
>>> a fairly tall order.
>>>
>>
>> Doing it early on would allow us to still apply later optimisations
>> (which would hopefully speed up the debugger a little bit).  Later
>> optimisations shouldn't affect the behaviour of the debugger, because
>> the should respect the impurity annotations of the debugger-transformed
>> code.
>
> *should* not will.  I understand the point you are making, but from
> a development point of view I think it would be easier to get the
> debugger working in a context where you are not simultaneously trying
> to debug bugs in 20 or so other transformations.
>

If you do it early, then you can still turn off any broken
optimisations that occur later.  If you do it later, then you
have to turn off all optimisations.

As I understand it, the transformed code is still valid Mercury, so
there should at least be some optimisations that will work on it.

Ian.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------