[m-rev.] for review: disable_warnings scope

Julien Fischer jfischer at opturion.com
Tue Jan 10 00:32:55 AEDT 2017

Hi Paul,

On Mon, 9 Jan 2017, Paul Bone wrote:

> Another option is to find whatever common code (should) exist between them
> and make that shared but otherwise keep them separate.  Then we will need to
> pass the ignore warnings scope information through to the MLDS backend.
> Depending on how most of the MLDS backend is written that could also be a
> fair amount of work.  We may also find that we need to do this anyway to
> suppress other warnings generated within the MLDS backend.
> This second option is tempting because it keeps these separate things
> separate.  Different backends have very different needs, even though both
> need to do TCO.  This is my "gut feeling" preference, but I'm beginning to
> think that if we can handle both backends in mark_tail_calls.m (and generate
> warnings there) then actually do TCO for each backend separately that may be
> best.  Provided that we make the logic in mark_tail_calls very clear with
> respect to which backends support which types of TCO.  This is currently my
> favorite option.

For the MLDS backend you may find this difficult. IIRC whether something
ends up being a tailcall or not depends to some extent on what the
HDLDS->MLDS code generator produces (which in turn is tied up with what
the target language is).  mark_tail_calls.m could only determine if
procedures are tailcalls in this case by essentially replicating a
largish chunk of what the MLDS code generator does.  That does not seem
terribly desirable.


More information about the reviews mailing list