DecompilationTests failures [was: About DecompilerTests >> decompilerDiscrepancies]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DecompilationTests failures [was: About DecompilerTests >> decompilerDiscrepancies]

Eliot Miranda-2


On Wed, Jan 20, 2010 at 12:41 AM, Michael Roberts <[hidden email]> wrote:
IIRC this suite is fairly specialised as part of eliot's closure work.
I think we disabled it from running because we did not have time to
fix it. I don't have an image at the moment but it would be better to
leave it alone if you can until someone can study the decompiler in
depth. Unless Eliot can comment?

Actually I suspect decompilerDiscrepancies is equivalent to my 3.8-derived image's DecompilerTests>>decompilerFailures which exists to list methods that will cause decompilation tests to fail and predates my work with closures.  My version reads

decompilerFailures
"here is the list of failures: DNU resulting in trying to decompile the following methods"

^ #((BalloonEngineSimulation circleCosTable "-0.3826834323650903 => -0.38268343236509 or -0.3826834323650902")
(BalloonEngineSimulation circleSinTable "-0.3826834323650903 => -0.38268343236509 or -0.3826834323650902")
(GeniePlugin primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount: "Cannot compile -- stack including temps is too deep")
(QPickable2D pick:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"
(QUsersPane userEntryCompare:to:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"
(TShaderProgram vertexStrings) "foo ifTrue: []. => foo. => ."
(TShaderProgram fragmentStrings) "foo ifTrue: []. => foo. => ."
(TWindow zoomWindow:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"

"(PNMReadWriter nextImage) (Collection #ifEmpty:ifNotEmpty:) (Collection #ifEmpty:) (Collection #ifNotEmpty:ifEmpty:) (Text #alignmentAt:ifAbsent:) (ObjectWithDocumentation propertyAt:ifAbsent:)")


They all list methods whose compilation of their decompilation won't match what one started with either because of limitations in the decompiler or optimizations in the compiler.  For example if one writes 
    foo ifTrue: [].
the compiler will emit that as foo, eliminating the branch around the empty block.  So when that is decompiled it'll decompile as
    foo.
and the compiler will then compile that as empty.  So ...

When you decompile the source code of the method containing foo ifTrue: [] it contains a parse node that prints as
    foo ifTrue: [].
But the bytecode contains only the code for
    foo.
so when you decompile that you get
    foo.
and when you compile that you get no bytecode generated for foo.

Other examples include cases where to:by:do: is decompiled as whileTrue:, where the precision of a written float exceeds the representation of underlying float objects, and so on.

I don't see the point of fixing these things in either the compiler or the decompiler.  They're legal Smalltalk, the optimizations the compiler performs is perfectly reasonable, and there seems no point in e.g. annotating the bytecode with information on the optimization so that the decompilation would be correct.  Hence I think we have to live with the work-around which is filtering-out expected failures.  Implementing the filter as a list is poor; better would be to have rules that match expected failures, but that's potentially a lot of tricky work for not much benefit. What would help is a) a simple tool to look at the discrepancies side-by-side (I have a workspace I can send you), and b) people who run the tests updating the filer-list with exceptions and documenting what causes each exception.

HTH
Eliot



Cheers mike

On Tuesday, January 19, 2010, Mariano Martinez Peck
<[hidden email]> wrote:
> Hi folks: does someone know what is this method for ?
>
> In my case, it has included the message saveImageSegments   which I rename it to saveImageSegments:
>
> So...what should I do ? I put saveImageSegments:  instead of saveImageSegments  or I just remove it from there?
>
> Thanks
>
> Mariano
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project