[Vm-dev] Suggested change for SpurMemoryManager>>#classAtIndex:

[Hernan Wilkinson]

well, I have the same problem but with the message #lengthOf:, but now the
behavior is weird.
If I have the following code, everything works fine:
typesSize := (objectMemory lengthOf: types) - 1.

If I remove the - 1, like this:
typesSize := objectMemory lengthOf: types.

I get redefinition of labels errors:
../../spurstack64src/vm/gcc3x-interp.c:4879:2: error: redefinition of label
'l46'
        l46:    /* end lengthOf:format: */;
        ^
../../spurstack64src/vm/gcc3x-interp.c:4693:2: note: previous definition is
here
        l46:    /* end lengthOf:format: */;
        ^

The thing is that in the first case #lengthOf: is not inlined but in the
second it is and it looks like that the label is not regenerated every time
it gets inlined.
 Is there a well know workaround for this? I mean, I could do:
typesSize := (objectMemory lengthOf: types) - 0.

 and it will compile but that is not the point.
 Also, why in the first case the code generator decides not to inline
#lengthOf: but it does in the second case?

Thanks!
Hernan.



On Tue, Oct 9, 2018 at 8:40 PM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> Hi,
>  I got compile errors when setting <inline: true> in a method I created.
>  The errors where a label redefinition such as:
> ../../spurstack64src/vm/gcc3x-interp.c:4790:2: error: redefinition of
> label 'l35'
>         l35:    /* end classAtIndex: */;
>         ^
> ../../spurstack64src/vm/gcc3x-interp.c:4634:2: note: previous definition
> is here
>         l35:    /* end classAtIndex: */;
>         ^
>
>  After some research I concluded that the problem was
> at SpurMemoryManager>>#classAtIndex: due to how it returns:
> ...
> classTablePage = nilObj ifTrue:
> [^nil].
> ^self
> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
> ofObject: classTablePage
>
>  I think the source code generator does not support correctly returning at
> different points when inlining the same method more than once.
>  So I changed that implementation to:
> ...
> ^classTablePage = nilObj
> ifTrue: [nil]
> ifFalse: [ self
> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
> ofObject: classTablePage ]
>
>  Doing so the compile errors were gone and the VM keeps working correctly.
>  Is this fix correct or does it have some performance hit I do not know?
>  Should I inform about this change with a PR? (Sorry about this question
> but I'm new to this vm stuff :-) )
>
>  Here is the complete code of the method:
> classAtIndex: classIndex
> <api>
> <inline: true>
> | classTablePage |
> self assert: (classIndex >= 0 and: [classIndex <= self tagMask or:
> [classIndex >= self arrayClassIndexPun and: [classIndex <= self
> classIndexMask]]]).
> classTablePage := self fetchPointer: classIndex >> self
> classTableMajorIndexShift
> ofObject: hiddenRootsObj.
> ^classTablePage = nilObj
> ifTrue: [nil]
> ifFalse: [ self
> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
> ofObject: classTablePage ]
>
>  Cheers!
>  Hernan.
> --
>
> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181010/e73b7f4e/attachment.html>