[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