<div class="gmail_quote">On Wed, Jul 8, 2009 at 5:26 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;">
A number of 64-bit operations can (and should) be implemented by the
native x86 codegen, to avoid the C calls. This should help even in the
presence of conversion optimizations.</blockquote><div><br>True. However, my combineConversions pass eliminates nearly all the cases that matter. ;) Improving the x86 codegen also won't be able to eliminate the Overflow tests in Int conversions the way my pass does.<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;">You can use the same technique that the Basis Library uses. There is an (undocumented) MLB path variable SEQINDEX_INT which expands to either "int32" or "int64", depending on the size of indices of the target platform.</blockquote>
<div><br>Sneaky. At this point, though, (assuming my optimization pass is ok to commit) the only benefit I get from using _prim is the lack of bounds checking.<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'm not sure why you call them "unsafe" versions. Your proposed PACK_WORD signature (with the "type word" specification) wouldn't be unsafe in any way.</blockquote><div><br>I meant PackWord versions without bounds checking. I would still really like exposed this somewhere. The Unsafe library, for example.<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;">In general, yes, conversion optimization should be a win. However, the "clean-up" optimizations aren't commonArg and knownCase. The SSA shrinker (ssa/shrink.fun) will perform the necessary simplifications:<br>
* copy propagation of x_3 = x_1 (replace all uses of x_3 by x_1 and<br>
eliminate the x_3 variable)<br>
* prim-app folding of Word64_eq (x_2, x_2) to true<br>
* case simplification of a manifest discriminant</blockquote><div><br>Ok, well those passes definitely do the job from the experiments I've done.<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;">
knownCase handles case simplification when the discriminant is only manifest on some of the incoming edges.</blockquote><div><br>Alright. Is my optimization pass in the wrong spot then? I put it right before commonSubexp.<br>
<br></div></div>