[Vm-dev] Fix for label duplications in Slang's case expansion

Guillermo Polito guillermopolito at gmail.com
Mon Jan 27 13:22:23 UTC 2020


Please, find attached a changeset with the test + method.
Still, my gut tells me this test is not representative enough of the error we had, but it’s better than nothing.



> El 24 ene 2020, a las 21:22, Eliot Miranda <eliot.miranda at gmail.com> escribió:
> 
> Hi Guille,
> 
> On Fri, Jan 24, 2020 at 7:57 AM Guillermo Polito <guillermopolito at gmail.com <mailto:guillermopolito at gmail.com>> wrote:
>  
> Hi all,
> 
> with Federico, a student from Argentina, we have found a problem in the label generation inside expanded cases in Slang.
> The problem comes from the fact that expanded cases (using the pragma <expandCase>, typically used for bytecodes), duplicate the entire tree with its inlines too, also duplicating labels inside it, which generates compilation errors due to label redefinition.
> 
> I’ve written a test for the case:
> 
>         | translation method codeGenerator |
>         method := self class >> #methodWithCases.
>         translation := method asTranslationMethodOfClass: TMethod.
>         codeGenerator := CCodeGeneratorGlobalStructure new.
>         codeGenerator addMethod: ((self class >> #expanded) asTranslationMethodOfClass: TMethod).
>         codeGenerator addMethod: translation.
> 
>         codeGenerator prepareMethods.
>         codeGenerator inlineDispatchesInMethodNamed: #methodWithCases localizingVars: #().
>         self assert: translation statements first cases first statements last isLabel.
>         self assert: translation statements first cases third statements last isLabel.
> 
>         self
>                 deny: translation statements first cases first statements last label
>                 equals: translation statements first cases third statements last label.
> 
> 
> 
> And I’ve made a fix that renames labels on each expanded case, to ensure non shared labels are unique within each case.
> I’ve put it in vmmaker's inbox. I hope there are no problems regarding timestamps, I’ve been careful about that ^^.
> 
> Well, all the timestamps are gone.  But it took me a couple of minutes to extend the Monticello browser to filter-out all the methods that only differ in timestamps.  And that is the point.  We are in control of our destiny using Monticello, not nearly as much as with git.  
> 
> Anyway, thank you.  i can now see the two changed methods, can easily integrate, and give them a meaningful timestamp.  Can you email me the test method?
>  
> 
> Commit + commit message below:
> 
> Name: VMMaker.oscog-GuillermoPolito.2676
> Author: GuillermoPolito
> Time: 24 January 2020, 4:27:09.847804 pm
> UUID: 49bcc820-4659-0d00-b258-043c01043dd2
> Ancestors: VMMaker.oscog-eem.2675
> 
> Fix in slang case statement expansion labels.
> 
> During expansion in case statements, trees are duplicated and expanded.
> However, labels inside those trees are duplicated using the same name, producing compilation problems due to label conflicts/redefinition.
> 
> This fix uses #renameLabelsForInliningInto: when expanding case statements to rewrite labels generating unique labels.
> 
> Cheers,
> Guille
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200127/bd244de2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VMCodeGenerationTest.GuillermoPolito.cs
Type: application/octet-stream
Size: 2224 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200127/bd244de2/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200127/bd244de2/attachment-0001.html>


More information about the Vm-dev mailing list