Re: Problem with MLton

On Thu, Feb 16, 2012 at 11:09 PM, Matthew Fluet <[email protected]> wrote:
> On Thu, Feb 16, 2012 at 10:38 PM, Matthew Fluet <[email protected]> wrote:
>> On Thu, Feb 16, 2012 at 7:41 AM, Lars Magnusson <[email protected]> wrote:
>>> We use MLton to build our system for automatic programming called
>>> ADATE, which has its own internal compiler capable of compiling a
>>> subset of SML. In the last year I have been working on upgrading this
>>> internal compiler to generate x86-64 code and to include a simple
>>> garbage collector in the runtime environment. For the last month I've
>>> been using MLton as a reference compiler for testing our internal
>>> compiler on a great number of different programs developed by the
>>> ADATE system i.e. I compile the generated programs with both compilers
>>> and compare the results.
>>>
>>> I've found an instance that gives a mismatch, and I've spent the last
>>> week investigating why my compiler fails to properly compile the
>>> program. I wasn't able to find the problem by investigating the
>>> generated code, so I thought I'd try executing the program on paper by
>>> hand to figure out where my code goes wrong. To my surprise my manual
>>> execution produced the exact same output as my compiler, so I did it
>>> again, and again, and all three times with the same result. I then
>>> decided to test the program on other existing ML compilers. I've tried
>>> the program on both SML/NJ and Poly/ML, and they both produce the same
>>> output as mine.
>>>
>>> I'm currently running MLton 20100608, but we have also tested the
>>> program on an older release (2006) with the same problems.
>>
>> ...
>>
>>> I'm hesitant about drawing this conclusion, but based on the
>>> observations I am forced to think that there's a bug in MLton.
>>
>> I agree that the evidence strongly suggests a bug in MLton.  I was
>> able to reproduce the "1 2 3 4 5 6 7" with MLton and the "1 2 3 5 6 7"
>> with SML/NJ, PolyML, and HaMLet.  The "f" and "gA1F7A0" are still
>> quite recognizable in the later intermediate representations, so I'm
>> hopeful that it won't take too much work to identify the offending
>> optimization pass.
>
> Seems to be a bug with the SSA redundant pass, which attempts to find
> variables (e.g., arguments) that are redundant due to the presence of
> another variable that always has the same value.  Compiling with
> "-drop-pass redundant" yields the "1 2 3 5 6 7" output.

I've committed a fix to the redundant SSA optimization; the commit
message includes a few more details about the bug and fix:
  http://mlton.svn.sourceforge.net/viewvc/mlton?view=revision&revision=7561

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/