Smalltalk › Squeak › Squeak VM

Moving simSelf into simStack and eliminating optStatus

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

Moving simSelf into simStack and eliminating optStatus

Hi Ronie, Hi Clément, Hi All,

one poor design decision I made when writing StackToRegisterMappingCogit was in keeping simSelf, the simulation stack entry for the receiver, separate from simStack, the simulation stack entries for the stack proper. I'm now at a point where I want to get RegisterAllocatingCogit working properly so that soon Clément and I can merge it into the SistaCogit and get much improved register allocation for Sista/Scorch. So I'm starting by duplicating StackToRegisterMappingCogit and making the changes in the city so I can verify that the existing one and the new one without simSelf or optStatus generate exactly the same code.

First of all, is that ok with both of you?

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.

_,,,^..^,,,_

best, Eliot

Ronie Salgado

Re: Moving simSelf into simStack and eliminating optStatus

Hi Eliot,

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.

Sounds fine by me.

BTW, we should have some talk during one of these days.

Best regards,

Ronie

2018-01-22 22:47 GMT-03:00 Eliot Miranda <[hidden email]>:

Hi Ronie, Hi Clément, Hi All,

one poor design decision I made when writing StackToRegisterMappingCogit was in keeping simSelf, the simulation stack entry for the receiver, separate from simStack, the simulation stack entries for the stack proper. I'm now at a point where I want to get RegisterAllocatingCogit working properly so that soon Clément and I can merge it into the SistaCogit and get much improved register allocation for Sista/Scorch. So I'm starting by duplicating StackToRegisterMappingCogit and making the changes in the city so I can verify that the existing one and the new one without simSelf or optStatus generate exactly the same code.

First of all, is that ok with both of you?

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.

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

Eliot Miranda-2

Re: Moving simSelf into simStack and eliminating optStatus

Hi Ronie, Hi Clément,

On Mon, Jan 22, 2018 at 9:37 PM, Ronie Salgado <[hidden email]> wrote:

Hi Eliot,

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.
Sounds fine by me.

BTW, we should have some talk during one of these days.

Cool. As soon as I've made this change I shall be able to focus :-)

Best regards,
Ronie

2018-01-22 22:47 GMT-03:00 Eliot Miranda <[hidden email]>:
Hi Ronie, Hi Clément, Hi All,

one poor design decision I made when writing StackToRegisterMappingCogit was in keeping simSelf, the simulation stack entry for the receiver, separate from simStack, the simulation stack entries for the stack proper. I'm now at a point where I want to get RegisterAllocatingCogit working properly so that soon Clément and I can merge it into the SistaCogit and get much improved register allocation for Sista/Scorch. So I'm starting by duplicating StackToRegisterMappingCogit and making the changes in the city so I can verify that the existing one and the new one without simSelf or optStatus generate exactly the same code.

First of all, is that ok with both of you?

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.

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

_,,,^..^,,,_

best, Eliot

Eliot Miranda-2

Re: Moving simSelf into simStack and eliminating optStatus

In reply to this post by Eliot Miranda-2

Hi Clément,

On Tue, Jan 23, 2018 at 12:06 AM, Clément Bera <[hidden email]> wrote:

It's ok to me.

Hopefully RegAllocatingCogit won't use this anyway.

Btw, I had this idea the other day. In the Scorch back-end, I do liveness analysis. So I could generate multiple kinds of pushTemp:, for example:
pushTempLastUse: => the temp is pushed, but it will never ever be used again so no need to write it back if it's a register and the register can be destroyed / mutated.
pushTempLastUseNoDeopt: => the temp is pushed, but it will never be used again except if a deoptimisation path is taken. It may need to be written back to stack later, but the register can be destroyed or mutated.
pushTempWillBeUsed: => the temp is pushed and but the temp value will be used again, keep the register live.

Yes! I like this a lot. My first cautionary thought is tat the middle one will be difficult to use because we always keep the stack ordered. Bit the first and the last should be easy to use in the JIT. Where this is useful is in the register allocation strategy for loops. The distinction between pushTempLastUse: and pushTempWillBeUsed: isn't useful for non-loop code because register allocation for temporaries occurs when a temporary is accessed. But for loops we simply copy back the live register set to the head of the loop on the first pass. Using pushTempLastUse: may mean mean we don't bother to copy back registers that aren't live at the end of the loop.

Anyway, we need RegisterAllocatingCogit to work and then we can explore this :-).

On Tue, Jan 23, 2018 at 2:47 AM, Eliot Miranda <[hidden email]> wrote:
Hi Ronie, Hi Clément, Hi All,

one poor design decision I made when writing StackToRegisterMappingCogit was in keeping simSelf, the simulation stack entry for the receiver, separate from simStack, the simulation stack entries for the stack proper. I'm now at a point where I want to get RegisterAllocatingCogit working properly so that soon Clément and I can merge it into the SistaCogit and get much improved register allocation for Sista/Scorch. So I'm starting by duplicating StackToRegisterMappingCogit and making the changes in the city so I can verify that the existing one and the new one without simSelf or optStatus generate exactly the same code.

First of all, is that ok with both of you?

Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that it is only ever called with nativeIndex being supplied from simNativeStackPtr. If you agree with me that that is the case would you object to me deleting ssFlushTo:nativeFlushTo: and implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]? This is a little cleaner, We can always make it more complicated later on if required, but right now I'd like to keep things as simple as possible.

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

--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

_,,,^..^,,,_

best, Eliot