<div class="gmail_quote">On Thu, May 5, 2011 at 3:32 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</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;">
although a slight variation on<br>
this proposal would be to add the allocation site index to the object<br>
type, inducing a distinct object type for every allocation site and<br>
simply use more bits for the object type index with 64-bit headers.<br>
(The advantage of this is that "small" programs that don't have more<br>
than 2^19 representation types and allocation sites could still be<br>
profiled under 32-bits.)<br></blockquote><div><br>I don't think this will work. Currently MLton uses object types to differentiate alternative datatypes. Under your proposal this would either not be possible or would inflate the cases considerably.<br>
<br>ie:<br>datatype foobar = FOO of x | BAR of y<br>val a = FOO 2<br>val b = FOO 3<br>val c = FOO 4<br>val d = BAR 5<br><br>Now when it comes time for a case statement to decide if something is FOO or BAR it will have three cases for FOO. (I realize that in this particular case there are so few cases that pointer tagging is used instead)<br>
<br>Still, as long as MLton uses the structure type tag this way, abusing the field further with call site information will be no fun.<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;">
1 is a bit more difficult, because one would need to thread the<br>
front-end type all the way through the computation.</blockquote><div><br>You've convinced me that the type info wouldn't be useful anyway since MLton combines types.<br><br></div></div>