[m-rev.] for review: disable_warnings scope

Paul Bone paul at bone.id.au
Wed Jan 11 15:27:31 AEDT 2017

On Wed, Jan 11, 2017 at 03:19:54PM +1100, Zoltan Somogyi wrote:
> This is about the LLDS backend.
> On Wed, 11 Jan 2017 15:06:17 +1100, Paul Bone <paul at bone.id.au> wrote:
> > > > Is the decision of what to make a tail call made twice?  Or do the later
> > > > passes simply follow the marked tailcalls?
> > > 
> > > The former.
> > 
> > Is that easy enough to change?  To remove the possability that these become
> > out-of-sync.
> The behavior of the LLDS code generator is dead easy to predict; there is
> no realistic possibility of the HLDS-based mark_tail_calls.m making a different
> decision than the LLDS code generator and optimizer, if it is run on the HLDS that
> the code generator works from.

That makese sense.

> I now see that the reason for the existence of ml_tailcalls.m is the fact
> this is *not* true for the MLDS backend. I will add documentation saying so
> to both source files.


> There *are* passes between mark_tail_calls.m and the LLDS code generator
> that can affect what calls are tail calls. One example is the deep profiling
> transformation. However, while this can transform calls that look like
> tail calls (to mark_tail_calls.m) into non-tail calls, we still don't want
> to generate non-tail-call warnings for these calls, since deep profiling
> destroys tail-recursion *wholesale*, and the warning is intended to be
> about *individual* places where a recursive call is prevented from being
> tail recursive by circumstances *specific* to that call site. (I am ignoring
> the deep-profiling transformation that aims to preserve tail recursion,
> since it hasn't worked for a while.)

Yes.  If anyone reading along is interested we discussed this earlier.


Paul Bone

More information about the reviews mailing list