[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.
Julien.
More information about the reviews
mailing list