Thank you very much for the detailed suggestions and feedback!<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 7:00 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+fun rules x3 (conversion as ((W2, W3, {signed=s2}), args, targs)) =<br>
<br>
Since the rules only apply to conversions, args must be a singleton and targs must be empty. Might be clearer to use the single arg and omit targs. (This does require a little more work at the point where the primapp is reconstructed.)</blockquote>
<div><br>I thought the targs was the type of the things in args? So targs must have one element in it.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+ val functions = + List.map<br>
Because the order of functions in an SSA program doesn't matter, List.revMap avoids an extra reversal.</blockquote><div><br>I know, but it's much easier to read a 'diff -u' of the pre.ssa and post.ssa this way. However, I guess I'm done debugging it this way now.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, the shrinker will not clear globals and the property will automatically be set for any global to which get was applied.<br>
val () = Vector.foreach (globals, Statement.clear)</blockquote><div><br>The shrinker is marking the globals? I don't think I am doing so. Should I also have run this pass on the globals? I wasn't clear on what computations (if any) globals can do.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think your current Function.dfs (for the analysis) followed by Vector.map (for the transformation) is probably sufficiently efficient (and certainly the clearest), but here are some alternative structures:</blockquote>
<div><br>Yes, I saw those tricks already when reading other optimization passes for tips. <br><br>How expensive is Function.dominatorTree? I had a much simpler version of the code where I used Tree.map to pre-order rewrite variables and then folded the tree into a list. I decided that the algorithm involved was probably prohibitively expensive. It would be very nice if there was a dfsMap function or something that let you rewrite blocks at finish.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As mentioned in the previous e-mail, commonArg doesn't really apply to the result of the combineConversions optimization. combineConversions should come before commonSubexp for the reasons you've noted earlier.</blockquote>
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I would have liked to see combineConversions come before some inlining, since it has the effect of shrinking the size of functions using conversions.</blockquote>
<div><br>It doesn't shrink the code that much, and if you don't inline first you might miss an opportunity to simplify the code.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I wonder if we shouldn't have an earlier round of commonSubexp (and thereby able to move combineConversions earlier) after contify2 and before inlineNonRecursive.<br>
</blockquote></div><br>When I compiled MLton with this optimization it affected a grand total of five conversions. So I think you're overestimating the impact on code size. The optimization has the most impact on tight loops involving conversions (typical for serialization code like I'm working on). Even there the code-size isn't greatly reduced.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
I meant PackWord versions without bounds checking. I would still really like<br>
exposed this somewhere. The Unsafe library, for example.<br></blockquote><br>
O.k. Alternatively, someone could write a bounds check elimination pass. ;-)<br></blockquote>
<br>How hard is this to do? For it to be useful it would have to work with loops.<br><br>