[BUG] Compiler Bug: Code generation with cascade and #caseOf: fails

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

[BUG] Compiler Bug: Code generation with cascade and #caseOf: fails

Christoph Thiede

Steps to reproduce:

Do it:

Object compile: '

foo: anObject

^ self foo

    flag: #bar;

    caseOf: { [#corge] -> [self grault: anObject] }

'


Error:

In TempVariableNode >> #isReferencedWithinBlockExtent:: MessageNotUnderstood: UndefinedObject >> #rangleIncludes:.

anInterval is nil.

In #computeCopiedValues:, blockExtent of the BlockNode {[#corge]} is nil.


This may be related to the observation made in http://forum.world.st/BUG-Cannot-compile-cascade-sent-to-block-td5108942.html that blockExtent can be nil.

Maybe we should handle optimized BlockNodes differently in this method?

Not (yet?) further investigated.


Best,

Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Compiler Bug: Code generation with cascade and #caseOf: fails

Eliot Miranda-2
Hi Christoph,

On Sat, Jan 18, 2020 at 12:10 PM Thiede, Christoph <[hidden email]> wrote:

Steps to reproduce:

Do it:

Object compile: '

foo: anObject

^ self foo

    flag: #bar;

    caseOf: { [#corge] -> [self grault: anObject] }

'


Error:

In TempVariableNode >> #isReferencedWithinBlockExtent:: MessageNotUnderstood: UndefinedObject >> #rangleIncludes:.

anInterval is nil.

In #computeCopiedValues:, blockExtent of the BlockNode {[#corge]} is nil.


This may be related to the observation made in http://forum.world.st/BUG-Cannot-compile-cascade-sent-to-block-td5108942.html that blockExtent can be nil.

Maybe we should handle optimized BlockNodes differently in this method?

Not (yet?) further investigated.


I see a contradiction.  The cascaded message "caseOf: { [#corge] -> [self grault: anObject]" has special = 0, which means it hasn't been optimized.  But both of its blocks are marked as being optimized.  We can't have that discrepancy.  Ether a cascaded caseOf: is (to be) inlined (special > 0) and its blocks are optimized, or it is not to be inlined and its blocks are not to be optimized.

Ah, the bug I believe is this:

ensureCanCascade: encoder
special > 0 ifTrue:
[special := 0.
receiver := originalReceiver.
selector := encoder encodeSelector: originalSelector.
arguments := originalArguments.
receiver isBlockNode ifTrue: [receiver deoptimize].
arguments do:
[:each|
each isBlockNode ifTrue:
[each deoptimize]]]

This assumes that optimized blocks only appear as arguments, not also in BraceNode elements, as they do in case statements.
Fixed in Compiler-eem.416

_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [BUG] Compiler Bug: Code generation with cascade and #caseOf: fails

Christoph Thiede

Wow, thanks for the fast fix and explanation! :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Sonntag, 19. Januar 2020 02:41:23
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [BUG] Compiler Bug: Code generation with cascade and #caseOf: fails
 
Hi Christoph,

On Sat, Jan 18, 2020 at 12:10 PM Thiede, Christoph <[hidden email]> wrote:

Steps to reproduce:

Do it:

Object compile: '

foo: anObject

^ self foo

    flag: #bar;

    caseOf: { [#corge] -> [self grault: anObject] }

'


Error:

In TempVariableNode >> #isReferencedWithinBlockExtent:: MessageNotUnderstood: UndefinedObject >> #rangleIncludes:.

anInterval is nil.

In #computeCopiedValues:, blockExtent of the BlockNode {[#corge]} is nil.


This may be related to the observation made in http://forum.world.st/BUG-Cannot-compile-cascade-sent-to-block-td5108942.html that blockExtent can be nil.

Maybe we should handle optimized BlockNodes differently in this method?

Not (yet?) further investigated.


I see a contradiction.  The cascaded message "caseOf: { [#corge] -> [self grault: anObject]" has special = 0, which means it hasn't been optimized.  But both of its blocks are marked as being optimized.  We can't have that discrepancy.  Ether a cascaded caseOf: is (to be) inlined (special > 0) and its blocks are optimized, or it is not to be inlined and its blocks are not to be optimized.

Ah, the bug I believe is this:

ensureCanCascade: encoder
special > 0 ifTrue:
[special := 0.
receiver := originalReceiver.
selector := encoder encodeSelector: originalSelector.
arguments := originalArguments.
receiver isBlockNode ifTrue: [receiver deoptimize].
arguments do:
[:each|
each isBlockNode ifTrue:
[each deoptimize]]]

This assumes that optimized blocks only appear as arguments, not also in BraceNode elements, as they do in case statements.
Fixed in Compiler-eem.416

_,,,^..^,,,_
best, Eliot