-
Notifications
You must be signed in to change notification settings - Fork 35
Preliminary deforestation implementation for hkmc2 #289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
object A | ||
object B | ||
|
||
// TODO: should fuse `A` and `B` with the pattern match in `f` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea why this doesn't happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I was looking into the explanation for this I realized that this may not be the best example to illustrate the issue here. I think a better one looks like this:
fun f1(x) = if x is A then 1 else 2
fun f2(x) = if x is A then 2 else 3
fun f3(x) = if x is A then 3 else 4
let p = if true then AA(A) else BB(B)
if p is
AA(x) then f1(x)
BB(x) then f2(x) + f3(x)
The fusion doesn't happen now (but can happen some time before) is because now the symbol for the first pattern variable (x
in the source program) in both branches (is AA(x) then ...; is BB(x) then ...
) is shared, which means that the program after lowering looks like:
if p is
AA then
param0 = p.x
x1 = param0
f1(x1)
BB then
param0 = p.x
x2 = param0
f2(x2) + f3(x2)
The shared param0
in both branches leads to both A
(in AA(A)
) and B
(in BB(B)
) flowing into all f1
, f2
and f3
, causing clash. Before, param0
is not shared (the first branch uses param0
and the second branch uses param1
), so that A
in AA(A)
could be fused, and only B
in BB(B)
couldn't get fused.
I said this program in the difftest file is not a good example because the fusion can also happen if we do not distinguish two call sites for the consumer f
.
I am trying to address this issue by generating different type variables for the shared param0
in different branches.
|
||
|
||
// TODO: fusion opportunity is lost | ||
// when instantiation ids of dtors are also tracked |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the comment. Care to explain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, here I mean that if we do not distinguish different call sites for consumers, we may be able to fuse again. Now this cannot fuse because there are two call sites for the inner
function (which turned out to be only a consumer), so two different inner
functions are considered to be called at these two call sites, causing strategy clash. This may also be related to the merging of consumers (in the next program in new-todo.mls
).
Superseded by #335 |
No description provided.