Open TimWhiting opened 1 year ago
@anfelor Do you have an idea whether there is a simple fix? It seems to make inlining counterproductive, especially when there is a borrowed parameter used in a match. And seems like a crucial missed opportunity for fusing the dup of the datatype with drops of it's fields when no reuse is possible (If reuse was possible then that would be different).
This also happens for field accessors on datatypes as well I believe - or anywhere a function gets inlined where the match scrutinee was borrowed in the function that gets inlined.
Hi Tim! I don't have a simple fix -- as far as I can tell fixing this would unfortunately involve rewriting most of the reuse analysis. I already implemented the FIP analysis to avoid this problem, and it seems not too hard to adapt, but I would still expect this to be a week or two of work. Have you run into a performance problem due to this?
No, I haven't run into big performance problems. It was just something I found as I was looking at the C code for my PhD research.
Take for example the following:
The (final core) code to extract a clause looks fine: It only dups the function we extract from the handler.
However when this gets inlined into the code to actually call the ask function we get the following, which dups the whole handler, then checks if that handler is unique (which it is obviously not since it just duped it). Followed by dropping / the unused pattern binders, and decrefing the handler. I'm not sure if the fusing of dup / drop should happen through a match based on certain conditions, or if the match binders should just be inserted into the borrowed environment instead of the owned environment since that seems to maybe be the only difference between the .select-ask code's match and the inlined. Maybe it's a combination of the two, it should be inserted into the borrowed environment if it is no longer used after the match?