[MLton] Re: PackWord to/from nonsense

[Matthew Fluet]

On Fri, 10 Jul 2009, Wesley W. Terpstra wrote:
> On Fri, Jul 10, 2009 at 2:37 AM, Matthew Fluet <fluet at tti-c.org> wrote:
>> The downside of this implementation is that the shifting and tagging (small
>> int inf) or vector creation (big int inf) for extending to an int inf and
>> untagging and shifting or vector extraction for truncating an int inf that
>> currently resides in basis-library/integer/int-inf0.sml would need to be
>> implemented in the compiler (perhaps expanding the IntInf_truncToWord and
>> IntInf_extdToWord in the combine conversions pass, since they wouldn't be
>> needed after).  It isn't terribly complicated code, but it is a little more
>> verbose to write in SSA, rather than in SML.
>
> Would there be a negative performance impact since this code would not be
> inlined any more? I am not concerned with "verbose" typing on my part. ;)

On the contrary --- the primitives would be counted (by default) as unit 
cost for the purposes of inline threshholds and so might be inlined in 
places where the original SML code might not have.  It isn't really a 
question of the IntInf conversions being inlined (they are quite small 
compared to the thressholds), but enabling the functions into which the 
conversions are inlined to themselves be inlined.

I think this is a reasonable way to go, but I would like to tackle it 
after the release; introducing the new primitives will touch a lot more of 
the compiler and the Basis Library implementation.  Not that I think there 
are any bugs in the combineConversions pass, but, if there were, it is 
easily disabled by a '-drop-pass combineConversions'; not so with 
introducing and expanding the new primitives.