[nem-en] patch for matching compiler (second take)
Marcin Grzeskowiak
fnord at silesianet.pl
Mon Oct 31 22:29:20 CET 2005
Hi
This is the second patch with new matching compiler. This
time it is for revision 5869 of Nemerle repository.
Changes since the first patch:
1) Span for all enum types (with or without System.Flags
attribute) is now -1 ("infinite") and as a result
the decision tree always contains a Decision.Failure
node for matching on enums (lack of this node was
responsible for problems mentioned in the earlier
post). I also changed Con.FindValueExcept ()
to mask some counter examples with enums (this
is similar to the way counter examples with nulls
are masked). The semantics changed a bit:
enum E { | R | G | B }
foo (e : E) : void
{
| R => {}
| G => {}
| B => {}
| _ => {}
}
Now the last clause ('_') is not reported as unused
(and it indeed matches foo (E.R | E.B)). This is
similar to the way semantics of null matching changed
in the previous patch ('_' also matches null).
I added a testcase positive/new-matching-enums.n
and modified frommcs/test-234.n
2) To solve the problem with wrong line numbers in
warnings (a test case where matching was embedded in
a try-with block) I changed function ImplicitCast () in
typing/Typer.n so it sets location of TExpr.TypeConversion
node to that of casted expression.
3) This patch includes TupleType.IsTupleMember ()
function (from Kamil with my corrections).
4) In test driver (testsuite/test.n) there is now additional
test before any process is killed, e.g.:
unless (nem_compile.WaitForExit (20000) || nem_compile.HasExited)
nem_compile.Kill ();
This solves the problems I had with InvalidOperationException
on Mono (but again, this just works and I didn't put much effort
into investigating the source of the problem).
5) The code to recognize shared nodes in decision tree changed
a bit. As a result all nodes marked as shared have in_deg > 1
also in the decision DAG and the generated TExpr is not
cluttered with unused labels.
I added new-matching-shared.n test case.
My list of TODO items is still not empty but I decided to not
work on any of them at least until I complete other parts of
my thesis. Here are some of the issues (maybe it is a good
idea to add them to the bug database):
- modify Con.FindValueExcept()/DecisionTreeBuilder.CheckMatching()
functions to not use exceptions to block unwanted warnings
(this was suggested by Kamil as throwing can be slow)
- I think that counter examples with 'null's are OK when the
null value was explicit in the matching, e.g.:
variant V { | R | G | B }
match (vv : V * V) {
| (R, _) => {}
| (G, _) => {}
| (B, _) => {}
| (null, R) => {}
}
this code could be reported with (null, B) or (null, G)
counter example, but currently all counter examples that
contain 'null' are blocked
- add optimization that uses GetVariantCode () for variants.
- matching compiler sometimes generates deeply nested if-else
instructions which then are translated to IL with 'br'
sequences similar to that one:
IL_0140: br IL_014a
IL_0145: br IL_0136
IL_014a: br IL_0154
IL_014f: br IL_0136
IL_0154: br IL_015e
IL_0159: br IL_0136
IL_015e: br IL_0168
IL_0163: br IL_0136
IL_0168: br IL_0172
IL_016d: br IL_00b2
IL_0172: br IL_017c
IL_0177: br IL_00b2
IL_017c: br IL_0186
IL_0181: br IL_00b2
IL_0186: br IL_0190
IL_018b: br IL_00b2
IL_0190: ret
(this is from:
match (x) {
| ([1,2], _) => {}
| (_, [1,2]) => {}
| _ => {}
}
)
I think that some of flow analysis optimizations could
help here (if I remember correctly there was something
like "elimination of jumps to jumps" doable on
basic-block DAGs).
- remove castclass instructions from the generated IL
code (one suggestion was to use stloc/ldoc pairs or
dup/pop)
- add some message to MatchFailureException whenever
the failure is due to unmatched null value
Marcin
*************************************************
Śląski Pasaż Handlowy - wpadnij na zakupy
http://pasaz.silesianet.pl
*************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-matching.patch
Type: application/octet-stream
Size: 59638 bytes
Desc: not available
Url : /mailman/pipermail/devel-en/attachments/20051031/0ae2f5f5/new-matching-0001.obj
More information about the devel-en
mailing list